| 00:07 | TabAtkins | will just go file a bug about ti. |
| 00:08 | <TabAtkins> | Do these bugs auto-cc the submitter, or do I need to manually put my email in the CC list? |
| 00:18 | <Hixie> | TabAtkins: the other elements that would need handling are all the flow ones, all the controls, dir="", lang="" (turning into unicode lang tags), things like <script> and <style> being hidden, <pre> not collapsing spaces but other things collapsing them, lists, <time>, it just gets more and more intractable |
| 00:19 | <TabAtkins> | Okay, then we skip that. All of those still return a useful value for their textContent, even if it's somewhat misformatted. <img> returns nothing, though. |
| 00:19 | <Hixie> | so don't use it |
| 00:19 | <Hixie> | it's really not a big problem |
| 00:20 | <Hixie> | i really don't see why <img> is important but, say, <br> is not |
| 00:21 | <TabAtkins> | For the reason I just stated. Losing a linebreak makes the text somewhat misformatted, but the text is still *there* and can be read. |
| 00:23 | <Hixie> | <bdo> then |
| 00:23 | <TabAtkins> | Again, misformatted, but still present. |
| 00:24 | <TabAtkins> | A human can parse it, even if it's somewhat confusing. |
| 00:24 | <Hixie> | O_o neht ,dettamrof yldab tsuj si siht kniht uoy fi |
| 00:24 | <TabAtkins> | I can read it! |
| 00:25 | <Hixie> | the model works fine as is, uing textContent -- it's trivial to understand, doesn't need any special cases, and is easy to predict |
| 00:25 | <TabAtkins> | And it would only come out like that if a parent element's text contained a bidi override character. |
| 00:25 | <hober> | M-x reverse-region is your friend :) |
| 00:25 | <Hixie> | as soon as we start adding magic, things start going down the path to RDFa |
| 00:25 | <JonathanNeal> | ): tla si tnaw I llA |
| 00:25 | <Hixie> | what's the use case for this anyway? what are you using microdata for for which you need alt? |
| 00:26 | <TabAtkins> | Dude, there's no magic. You want text, you get text, including the text equivalent of things that have text equivalents. |
| 00:26 | <TabAtkins> | Sigh. <h1 itemprop="fn org"><img src=foo alt="Example Corp"></h1> |
| 00:27 | <Hixie> | having to check each element's namespace and localname to see if it's an <img> from which to grab alt="" is magic. |
| 00:27 | <Hixie> | why would you use an image there? |
| 00:27 | <Hixie> | just use <h1>Example Corp</h1> |
| 00:27 | <TabAtkins> | Because that's extremely common. |
| 00:28 | <TabAtkins> | That way you can have a fancy image logo, while still having proper text for Google and screen readers. |
| 00:28 | <Hixie> | and you're putting a vcard on it? o_O |
| 00:28 | <TabAtkins> | Is there something wrong with that? |
| 00:28 | <Hixie> | i fail to see any point |
| 00:28 | <TabAtkins> | A Contact Us page is a fine place to put a vcard. |
| 00:29 | <TabAtkins> | Or, perhaps you put the business's contact information in a sidebar on each page (my old company does precisely this). |
| 00:29 | <Hixie> | sure, just stick it in a data: URL so I can actually use it, rather than requiring that I extract it from microdata :-P |
| 00:29 | <TabAtkins> | Might as well mark it up properly. |
| 00:29 | <JonathanNeal> | <section><h1>Companies using us</h1><article><h1 itemprop="fn org"><img src="google.png" alt="Google, Inc." /></h1></article></section> |
| 00:29 | <Hixie> | btw since you're going to have to have the "n" property elsewhere anyway, why can't you just do "fn" and "org" there too? |
| 00:30 | <JonathanNeal> | And in that <article>, you could be describing Google in some way. |
| 00:30 | <Hixie> | this really seems like far too overenthusastic use of microdata |
| 00:30 | <TabAtkins> | Hixie: ?_? |
| 00:30 | <TabAtkins> | I don't understand what you mean by your previous statement. |
| 00:30 | <Hixie> | for "n" you have to use itemscope |
| 00:30 | <Hixie> | rigt? |
| 00:30 | <Hixie> | so why is the duplication there ok but meanwhile you're trying really hard to avoid it here? |
| 00:31 | <TabAtkins> | Why do you need to use "n"? This is a company name. The correct idiom is to apply both "fn" and "org" to it. |
| 00:31 | <TabAtkins> | No "n" required. |
| 00:31 | <Hixie> | vcard requires "n" for all vcards |
| 00:31 | <TabAtkins> | Yes, and the microformat vocabulary allows it to be omitted and extracted from the fn, if present. |
| 00:31 | <Hixie> | the microdata vcard vocab has none of that magic |
| 00:31 | <TabAtkins> | If the Microdata embedding of such doesn't allow that, it's a bug in Microdata. |
| 00:33 | <Hixie> | speak to foolip, he argued for the magic to be removed since it basically doesn't work and isn't specified anywhere |
| 00:33 | <TabAtkins> | It's specified on the Microformats wiki! |
| 00:34 | <Hixie> | "specified" isn't the word i would use |
| 00:34 | <TabAtkins> | If I can believe the wiki, you don't need any of the implied fn magic. If you're doing an org name, the org name should be specified as the value of both "fn" and "org", and *no* value shoudl be specified for the "n" properties (they should all be blank). |
| 00:34 | <Hixie> | for example, if n="TAMURA Kent", what is the vcard output? |
| 00:35 | <Hixie> | yeah for org="" the magic isn't quite so bad |
| 00:35 | <TabAtkins> | If n equals that? That's wrong. We're talking fn. |
| 00:35 | <Hixie> | er |
| 00:35 | <Hixie> | if fn="TAMURA Kent" |
| 00:35 | <Hixie> | what is the vcard output for "n" |
| 00:35 | <Hixie> | is "Kent" the given name or the surname? |
| 00:36 | <TabAtkins> | Then it gets split into given-name="TAMURA" and family-name="Kent". |
| 00:36 | <Hixie> | which is wrong |
| 00:37 | <TabAtkins> | Sure. But it's right for most of the world. And if your particular name-formatting practices dont' match that, just specify a full n value. |
| 00:37 | <Hixie> | uh, it's wrong for the majority of the population of earth |
| 00:37 | <Hixie> | it's right for the US and some parts of europe |
| 00:37 | <TabAtkins> | This makes the majority of hcards in the world much less verbose. |
| 00:37 | <TabAtkins> | It's wrong for East Asia. Where else? |
| 00:38 | <Hixie> | a number of parts of europe |
| 00:38 | <TabAtkins> | Details? I've never heard of such a thing. |
| 00:38 | TabAtkins | may simply be ignorant. |
| 00:39 | <Hixie> | i don't know the details, unfortunately |
| 00:39 | <Hixie> | foolip is the man to ask |
| 00:39 | Hixie | is not a fan of any of these data systems |
| 00:39 | <TabAtkins> | Will do. In the meantime, we're talking about "fn org", which is a completely different matter. |
| 00:40 | <Hixie> | i really don't understand why anyone would ever care to get a vcard from a web page, personally |
| 00:40 | <TabAtkins> | It's not important that you do. It's just important for you to understand that hCard exists, and is popular, for precisely that reason. |
| 00:40 | <Hixie> | hcard is hardly that popular |
| 00:40 | <TabAtkins> | Go ask Tantek for usage statistics. |
| 00:41 | <TabAtkins> | If we're talking about marking up metadata, it and licensing information are, I think, the most popular use-cases. |
| 00:41 | <Hixie> | you have been drinking too much kool-aid :-) |
| 00:41 | <Hixie> | licensing information i can sort-of buy |
| 00:42 | <Hixie> | that one definitely doesn't need alt="" though |
| 00:42 | <TabAtkins> | Sure. |
| 00:55 | <TabAtkins> | Anyway, submitted bug 9533 about it. |
| 00:57 | <Hixie> | did you mean to put it in "future versions"? |
| 00:58 | <TabAtkins> | Microdata is no longer part of HTML5, right? Or did I just skip seeing the Microdata entry? |
| 00:58 | <Hixie> | oh i just treat it as part of html5 |
| 00:58 | <Hixie> | "future versions" doesn't appear on my radar |
| 00:58 | <TabAtkins> | All right, that's cool. |
| 00:58 | <TabAtkins> | So, change it to "spec bugs"? |
| 00:59 | <Hixie> | i can do it |
| 00:59 | <TabAtkins> | kk |
| 01:20 | <MikeSmith> | so Chrome supports the File API now, I gues? |
| 01:20 | <TabAtkins> | If you were in the office, you could ask. |
| 01:20 | TabAtkins | doesn't know. |
| 01:21 | <MikeSmith> | reading http://gmailblog.blogspot.com/2010/04/drag-and-drop-attachments-onto-messages.html |
| 01:21 | <MikeSmith> | TabAtkins: If I were in the office? |
| 01:21 | <MikeSmith> | you mean if I was the other Mike Smith? |
| 01:21 | <TabAtkins> | ... Sorry, I didn't look too closely and thought you were Hixie. |
| 01:22 | <MikeSmith> | me and Hixie are like twins |
| 01:22 | <MikeSmith> | or like Wolverine and Sabretooth |
| 01:22 | <TabAtkins> | It's true. That's why you have to wear a hat at standards meetings. |
| 01:22 | <Hixie> | hah |
| 01:22 | <MikeSmith> | heh |
| 01:23 | <MikeSmith> | TabAtkins: one of the Chrome product managers is named Mike Smith |
| 01:23 | <MikeSmith> | in case you didn't know |
| 01:23 | <TabAtkins> | I'd given half-decent odds that there's a Mike Smith working for every browser company. |
| 01:23 | <TabAtkins> | Maybe not Opera, but who knows? |
| 01:23 | <MikeSmith> | yeh |
| 01:31 | <MikeSmith> | uh, I just checked in Gmail with Minefield and Chrome dev-channel on OSX, and the drag-and-drop file attachment thing don't seem to work |
| 01:42 | <Hixie> | MikeSmith did work for opera for a bit iirc, so maybe that counts for them |
| 01:44 | <TabAtkins> | I'll take it. |
| 01:54 | <Hixie> | hm, the hardware limitations clause is an interesting point |
| 01:54 | <Hixie> | it doesn't quite handle this case |
| 01:55 | <Hixie> | but we could make it handle this case and then turn it into a MUST |
| 03:05 | <kennyluck> | Morning, MikeSmith. |
| 03:11 | <MikeSmith> | kennyluck: hey |
| 03:11 | <MikeSmith> | annevk: i'm in the breakroom area |
| 03:11 | <annevk> | kk |
| 03:26 | <MikeSmith> | does html5-based drag-and-drop in Gmail only work on Windows maybe? |
| 03:27 | <MikeSmith> | still not working for me at least in Chrome and Minefield on OSX |
| 03:31 | <TabAtkins__> | Man, what computer do I still have on that is using TabAtkins_? |
| 03:31 | TabAtkins__ | is puzzled. |
| 03:32 | TabAtkins__ | has shut down the one that was claiming TabAtkins__, allowing me to change from ___ to __. |
| 05:38 | <MikeSmith> | I really like this page design: http://www.kuroge-wagyu.com/bc/delivery.html |
| 05:38 | <MikeSmith> | all sites should be like that |
| 05:39 | <kennyluck> | orz |
| 05:39 | <kennyluck> | a picture, huh... |
| 05:45 | <MikeSmith> | the table use is great as well |
| 05:47 | <MikeSmith> | I would like to be the guy who got paid to make that site |
| 05:52 | <MikeSmith> | kennyluck: click in the part where it TOP DELIVERY TAKEOUT etc. |
| 05:54 | <othermaciej> | hey everybody |
| 05:55 | <MikeSmith> | greetings |
| 05:56 | <MikeSmith> | othermaciej: dunno if you saw this yet: http://gmailblog.blogspot.com/2010/04/drag-and-drop-attachments-onto-messages.html |
| 05:57 | <othermaciej> | I have |
| 05:57 | <othermaciej> | not sure why they didn't make it work in Safari (we support the relevant features afaik) |
| 06:00 | <MikeSmith> | as far as I can tell so far, it doesn't work on OSX at all |
| 06:00 | <MikeSmith> | unless I am missing something |
| 06:01 | <MikeSmith> | maybe the platform file-system interaction part is only implemented for Windows so far? |
| 06:28 | <annevk> | TabAtkins, e.g. how would "Anne van Kesteren" work with this splitting system? |
| 06:31 | <othermaciej> | MikeSmith: is it a plugin or something? |
| 06:31 | <othermaciej> | I thought it was using standard file drag & drop functionality |
| 06:32 | <MikeSmith> | yeah, I thought so too.. but the interaction between the browser and the OS file system is platform code, right? |
| 06:36 | <othermaciej> | yeah but file DnD in WebKit was implemented on Mac first |
| 06:57 | <annevk> | TabAtkins, also, DOM insertion is not random, it is defined by the HTML parser |
| 06:58 | <JonathanNeal> | heyo |
| 06:59 | <TabAtkins__> | annevk: It woulnd't. It only tries to do any optimizations if you have a single value after splitting spaces (in which case it assumes it is a nickname) or if you have two values (in which case it assumes given, then family name). |
| 07:00 | <JonathanNeal> | TabAtkins__, did we get alt? |
| 07:01 | <TabAtkins__> | I have a bug. It's rejected right now, but I'm trying to gather some support from one of our Google teams |
| 07:01 | <othermaciej> | which bug? |
| 07:04 | <TabAtkins__> | 9355? something like that. |
| 07:06 | <annevk> | TabAtkins__, ah okay, but that indeed fails |
| 07:07 | <TabAtkins__> | annevk: You have any idea of non-east asian areas where it's common to write a name with family-name first, given-name last? |
| 07:07 | <annevk> | Hungary according to Wikipedia |
| 07:08 | <TabAtkins__> | Interesting. |
| 07:08 | <othermaciej> | this is true |
| 07:08 | <annevk> | optimizing for common usage failed to work out with e.g. <meter> and <progress> so I doubt it will here |
| 07:12 | <annevk> | I should add perceived* to that |
| 07:14 | <TabAtkins__> | othermaciej: 9533 is my bug, actually. |
| 07:16 | <MikeSmith> | TabAtkins, I thought I had heard before that family-name first is used in Finland in at least some cases |
| 07:18 | <hsivonen> | MikeSmith: it's rare |
| 07:19 | <hsivonen> | MikeSmith: doesn't happen in speech |
| 07:19 | <MikeSmith> | ok |
| 07:19 | <hsivonen> | MikeSmith: I guess some people think it's more official or something |
| 07:19 | <hsivonen> | MikeSmith: I've seen it in email From fields |
| 07:19 | <hsivonen> | MikeSmith: but very, very rarely |
| 07:19 | <hsivonen> | MikeSmith: definitely not common enough to cry i18n for failure to support that oddity |
| 07:20 | <MikeSmith> | I see |
| 07:20 | <MikeSmith> | hsivonen: in mail From fields to people put a comma after the family-name part? |
| 07:20 | <MikeSmith> | because I do see that in business mail in English too sometimes |
| 07:21 | <hsivonen> | MikeSmith: I think I've seen it without the comma |
| 07:23 | <MikeSmith> | has Twitter said what format their Annotations mechanism uses? |
| 07:24 | <MikeSmith> | are their docs yet for the API? |
| 07:24 | <micheil> | MikeSmith: i think so |
| 07:25 | <micheil> | MikeSmith: actually not yet, but I may be able to find out off the guys who went to chirp. |
| 07:25 | <micheil> | MikeSmith: I'm pretty sure it'd just be a json type blob |
| 07:26 | <micheil> | as it is, to update a status, you have to POST, so to add arbitrary json data to the body of that request would be easiest |
| 07:26 | <MikeSmith> | ok |
| 07:27 | <JonathanNeal> | So ... we did yet alt? |
| 07:38 | <MikeSmith> | JonathanNeal: ? |
| 07:38 | <JonathanNeal> | Earlier there was a large discussion going on about microdata. |
| 07:39 | <JonathanNeal> | In particular, whether or not folks would modify the spec to allow for the alt="text" to be read, example @ http://sandbox.thewikies.com/html5-layout/ |
| 07:43 | <MikeSmith> | JonathanNeal: is the alt value in that case a functional equivalent of the image or is it a label or something? |
| 07:44 | <JonathanNeal> | it is the textual representation of the image. |
| 07:51 | <JonathanNeal> | That answer was bunk? |
| 07:54 | <JonathanNeal> | TabAtkins had a better explanation than I |
| 07:55 | <hsivonen> | what's the recommended way of building a Theora movie in Ogg container without soundtrack from a sequence of PNG images? |
| 07:56 | <hsivonen> | googling shows results from 2006, so I expect the state of the art may have advanced |
| 07:57 | <hsivonen> | hmm. http://wiki.povray.org/content/HowTo:Encode_animations_as_Ogg_Theora_Video might still be the state of the art |
| 08:02 | <hsivonen> | There's still a couple of Cinepak videos on my site that I made when I was in high school. I should re-encode those as Theora, even though those videos are a lot less impressive today than they were back then |
| 08:03 | <zcorpan> | hmm, should we make <figcaption> imply </p>? |
| 08:04 | <annevk> | <legend> wheee |
| 08:06 | <othermaciej> | it's probably unwise to make new things imply </p> |
| 08:06 | <othermaciej> | though I guess the spec probably already does that? |
| 08:06 | <annevk> | not that <legend> implies </p> |
| 08:06 | <annevk> | othermaciej, yes |
| 08:06 | <annevk> | othermaciej, e.g. <figure> does |
| 08:06 | <annevk> | othermaciej, and <section> and all |
| 08:06 | <othermaciej> | <p> inside <figure> seems too obscure a case for <figcaption> to imply </p> |
| 08:07 | <annevk> | a poem is not that obscure |
| 08:07 | <annevk> | it's in the spec even :) |
| 08:07 | <annevk> | (but with a </p>) |
| 08:08 | <othermaciej> | using a non-preformatted poem in a figure is, I think a somewhat obscure use of figure |
| 08:16 | <zcorpan> | "Please ensure that your comment is descriptive enough that the editor can understand it." |
| 08:17 | <zcorpan> | wtf? |
| 08:17 | <zcorpan> | what's the magic phrase i need to use? |
| 08:17 | <zcorpan> | Hixie: ^ |
| 08:21 | <annevk> | more than one word |
| 08:21 | <annevk> | maybe? |
| 08:21 | <zcorpan> | my comment is "Consider the poem example of figure. It should be possible to omit the </p> tag there. Maybe we should make <figcaption> imply </p> in the parser." |
| 08:21 | <annevk> | oh dunno then |
| 08:24 | <zcorpan> | } else if ((text.length <= 5) || (text.indexOf(' ') != text.lastIndexOf(' '))) { |
| 08:24 | <zcorpan> | showAlert('Please ensure that your comment is descriptive enough that the editor can understand it.'); |
| 08:26 | <zcorpan> | javascript:(function(){text='Consider the poem example of figure. It should be possible to omit the </p> tag there. Maybe we should make <figcaption> imply </p> in the parser.';alert(text.indexOf(' ') != text.lastIndexOf(' '))})() |
| 08:26 | <zcorpan> | true |
| 08:26 | <zcorpan> | Hixie: maybe you meant to use == instead of != there? |
| 08:29 | <annevk> | weird that nobody else noticed that |
| 08:34 | <zcorpan> | Hixie: i also didn't get any notification when the bug was successfully submitted |
| 08:39 | <MikeSmith> | http://wiki.whatwg.org/wiki/PragmaExtensions -> "Error: 1205 Lock wait timeout exceeded; try restarting transaction (database.wiki.whatwg.org)" |
| 08:39 | <annevk> | hybi list o_O moments |
| 08:40 | <annevk> | those people just wanna go in circles |
| 08:40 | <annevk> | creative bug filing zcorpan :) |
| 08:42 | <othermaciej> | I need to catch up on all that mail this weekend |
| 08:48 | <zcorpan> | annevk: what was i supposed to do? :) |
| 08:49 | <hsivonen> | nessy: W3C standards don't, in general, have the requirement not to break the Web |
| 08:49 | <nessy> | that's plain stupid - who made up that rule? ;) |
| 08:50 | <nessy> | joking aside: I still owe you an answer to your email |
| 08:50 | <nessy> | had a rather busy week, but will get to it |
| 08:50 | <nessy> | sorry about the delay |
| 08:53 | <annevk> | what would break the Web? |
| 08:54 | <hsivonen> | annevk: the money behind TTML or the money behind XSL-FO deciding to take either in a direction where the formatting behavior no longer matches the CSS formatting behavior for the same-named concepts |
| 08:54 | <nessy> | XSL-FO is really unfortunate |
| 08:54 | <annevk> | not sure if it's really bad by the way if we have some breakage with the SRT format; in the end deployment to Web browsers is somewhat new and require a few changes anyway |
| 08:55 | <annevk> | even without XSL-FO TTML is a terrible format imo |
| 08:55 | <nessy> | I don't disagree |
| 08:55 | <annevk> | as you showed hand authoring is way too hard |
| 08:55 | <nessy> | but it is being implemented all over the place |
| 08:55 | <annevk> | that's what people say about XForms too |
| 08:55 | <hsivonen> | nessy: interoperably? |
| 08:55 | <nessy> | I am not defending the best solution (which I think would be a new format) |
| 08:55 | <hsivonen> | nessy: what annevk said |
| 08:55 | <nessy> | I am defending a compromise |
| 08:56 | <hsivonen> | sXBL was a compromise |
| 08:56 | nessy | goes looking up sXBL |
| 08:57 | <annevk> | anything that involves re-using TTML will result in a fork or enormous bloat in the browser |
| 08:57 | <nessy> | yeah, I think the implementations are interoperable |
| 08:57 | <nessy> | most only implement the baseline anyway |
| 08:58 | <annevk> | though likely it will be both a fork and enormous bloat |
| 08:58 | <nessy> | I still don't understand what the problem with defining a mapping is |
| 08:58 | <nessy> | for SRT we define a mapping |
| 08:58 | <nessy> | nobody has a problem with that |
| 08:58 | <annevk> | for SRT we define the format I think |
| 08:58 | <nessy> | for TTML we define a mapping and it's a big problem |
| 08:58 | <nessy> | yeah, and then implement mappings |
| 08:58 | <annevk> | what do you mean mapping? |
| 08:59 | <annevk> | like text/plain is a mapping to an HTML file with a <pre> element? |
| 08:59 | <nessy> | what the start time means, what the end time means, how the text is to be parsed |
| 08:59 | <nessy> | yeah, somewhat like that |
| 08:59 | <annevk> | SRT is a simple format |
| 09:00 | <annevk> | a simple text-based format of which the Web has a couple already |
| 09:00 | <nessy> | not when we throw all the baggage at it that it needs |
| 09:00 | <annevk> | it makes sense |
| 09:00 | <annevk> | SRT-HTML would be a new format |
| 09:00 | <annevk> | it's just an idea of how we could approach the richer captioning format |
| 09:01 | <nessy> | that still has to be parsed |
| 09:01 | <annevk> | sure |
| 09:01 | <nessy> | most of the mapping of elements will easily map directly on a HTML element |
| 09:01 | <annevk> | as hsivonen defined it could reuse a lot of what already needs to be defined for SRT |
| 09:01 | <nessy> | that makes it easy |
| 09:02 | <nessy> | yeah, haven't looked at hsivonen's work yet, sorry |
| 09:02 | nessy | should really work on this client project |
| 09:02 | <annevk> | TTML is not easy |
| 09:02 | <nessy> | creating it isn't |
| 09:02 | <nessy> | but parsing it isn't hard |
| 09:03 | <annevk> | e.g. <color> does not match any concept of what browsers already have |
| 09:03 | <nessy> | ? |
| 09:03 | <annevk> | http://www.w3.org/TR/ttaf1-dfxp/#style-value-color |
| 09:04 | <annevk> | i.e. compared to CSS a-value is different, there's no #rrggbbaa format, CSS has #rgb, system colors, etc. |
| 09:05 | <nessy> | that is not an element - it's describing the value that an attribute can take, IIUC |
| 09:05 | <annevk> | that's still parsing |
| 09:06 | <nessy> | sure - but it can be easily mapped onto an existing CSS value |
| 09:06 | <annevk> | that parsing XML is not hard is somewhat self-evident if you already have an XML parser |
| 09:06 | <annevk> | nessy, we'd need a new TTML-<color>-value parser first |
| 09:06 | <annevk> | it's insane |
| 09:06 | <annevk> | there's also bugs it seems |
| 09:06 | <zcorpan> | i think the point is not how hard it is to implement, the point is reuse of existing code |
| 09:07 | <annevk> | e.g. familyName can be any string except for quotation characters, but that gives parsing problems when used in http://www.w3.org/TR/ttaf1-dfxp/#style-attribute-fontFamily |
| 09:07 | <nessy> | I regard it like supporting different image formats |
| 09:08 | <nessy> | every image format brought in another decoding library |
| 09:08 | <nessy> | I regard formats of external timed text as exactly the same |
| 09:08 | <nessy> | it's just decoding a file |
| 09:08 | <hsivonen> | I'm not so concerned about parsing as I am about how exactly the stuff interacts with the CSS frame constructor, with the event loop, etc. |
| 09:09 | <jgraham> | A web browser is just decoding a file |
| 09:09 | <nessy> | I'm sure that in the long run we have to deal with much more than SRT and TTML, btw |
| 09:09 | <jgraham> | For large values of just |
| 09:10 | <annevk> | if it's all so easy I'd love to see a proper spec |
| 09:10 | <annevk> | not really convinced that TTML is one |
| 09:10 | <nessy> | I am just really concerned that if we do not specify how TTML is to be parsed, we end up with e.g. IE implementing a parsing that they like, then other browser vendors following and we have diverging behaviour |
| 09:11 | <nessy> | we will get huge flak from the a11y community if we ignore TTML |
| 09:11 | <nessy> | but yeah - all this is kinda akademic unless we specify the parsing |
| 09:11 | zcorpan | expects a flak from the a11y community regardless of what we do |
| 09:11 | <hsivonen> | nessy: we aren't ignoring it. more like rejecting it after taking a good look |
| 09:12 | <annevk> | the a11y community that designs this stuff could really do with some lessons from the people that made HTML/CSS |
| 09:13 | <nessy> | ok, in this case I will just sit back and watch the battle ;) |
| 09:13 | <hsivonen> | nessy: about mapping: if you map TTML to XSL-FO to CSS frame tree, you need a new frame constructor |
| 09:13 | <hsivonen> | FAIL |
| 09:13 | <hsivonen> | nessy: if you map TTML to style sheet plus DOM, you need to do it on the main thread |
| 09:13 | <nessy> | I'd avoid going via XSL-FO |
| 09:13 | <annevk> | all this namespace loving complexity (also with WAI-ARIA until we got involved) is just a major fail |
| 09:14 | <nessy> | can't style sheet plus DOM be thrown into an iframe? |
| 09:15 | <nessy> | there are two things that we are mixing up right now: the parsing of the file (basically the "decoding") and how to display it |
| 09:15 | <nessy> | I think we need to keep them separate |
| 09:15 | <annevk> | my comments are highly related though |
| 09:15 | <nessy> | what you do when you have some html-snipped for a certain time frame is independent of the file fromat |
| 09:16 | <annevk> | if they had taken lessons from the HTML/CSS people we would not be facing a lot of these questions |
| 09:16 | <nessy> | annevk, I don't like namespaces either |
| 09:16 | <nessy> | annevk, I think you're right - I wrote about DFXP last year and criticised that, too |
| 09:16 | <annevk> | with "namespace loving complexity" i mean more than just the complexity; i.e. designing things on top of XHTML2, XSL-FO, etc. |
| 09:16 | <nessy> | but DFXP/TTML was not developed as a web format, unfortunately |
| 09:17 | <nessy> | it was the time when things were done that way |
| 09:17 | <nessy> | a lot of specs came out of the W3C in that manner during that time |
| 09:17 | <nessy> | I blame history |
| 09:17 | <nessy> | it's unfortunate - just like XHTML2 is unfortunate |
| 09:17 | <jgraham> | TTML has the air of being designed for a situation where a bunch of people in suits turn up to help you do accessibility. SRT has the air of something designed so that some guy in his pants in his basement can subtitle anime. Historically the successful parts of the web have been much closer to the guy-in-his-basement design than the people-with-suits design |
| 09:18 | <jgraham> | It would be surprising if this case were different |
| 09:18 | <nessy> | that's why I fought for SRT in the a11y group |
| 09:18 | <hsivonen> | nessy: throwing style sheet plus DOM in an an anonymous iframe is what I suggested |
| 09:18 | <nessy> | yes, indeed, and that's a good idea |
| 09:19 | <hsivonen> | nessy: the point is that I had a concrete suggestion of what goes into the DOM without the complexity of a "mapping" |
| 09:19 | <nessy> | it keeps it separate from the rest |
| 09:19 | nessy | really has to make time to read the proposal |
| 09:19 | nessy | really should be having this discussion at a different time |
| 09:20 | <nessy> | sorry - I have to go, but I will get back to you, promised |
| 09:22 | <annevk> | the thing I liked about hsivonen's SRT-HTML was that SRT itself could also be mapped this way and that therefore it would also allow for styling SRT-based subtitles |
| 09:28 | <zcorpan> | it'd be nice to support the SRT legacy so authors can just use their existing subtitles (if they're SRT) |
| 09:31 | zcorpan | looks at http://wiki.xiph.org/index.php/OggKate |
| 09:32 | <MikeSmithX> | Cloud Print is not a "new approach to printing", not by a long shot .. it's actually quite an established approach that some companies have based entire businesses on |
| 09:32 | <MikeSmithX> | e.g., going back the Palladium project at MIT |
| 09:33 | <MikeSmith> | and Dazel in Austin |
| 09:33 | <MikeSmith> | where I worked for a while and where Dan Connolly worked for a time too |
| 09:34 | <MikeSmith> | but NIH and all applies as usual, I guess |
| 09:35 | <annevk> | i bet your approach didn't have Google account tie-in |
| 09:35 | <MikeSmith> | nope |
| 09:36 | <MikeSmith> | so I guess that's what the "new approach" amounts to |
| 09:36 | <annevk> | it also seems somewhat novel that you can address the printer settings from a page |
| 09:38 | hsivonen | replied to the whatwg list about captioning |
| 09:39 | <hsivonen> | zcorpan: Kate also has the problem of importing a whole new text layout engine to a browser |
| 09:40 | <zcorpan> | so it seems |
| 09:42 | <MikeSmith> | annevk: yeah, but the main part that really makes that novel is the whole idea of a page being an application, not really anything specific about being able to print |
| 09:42 | <MikeSmith> | but anyway |
| 09:44 | <hsivonen> | it's unclear to me what problem the cloud print system solves |
| 09:45 | <hsivonen> | is the problem being solved that printers today don't ingest a PDF via the IPP? |
| 09:45 | <hsivonen> | but in Google's diagram, legacy printers needed a local intermediate box anyway |
| 09:45 | <annevk> | i think the major thing it solves is that apps can skip the OS when talking to printers |
| 09:45 | <hsivonen> | so why not put the PDF to printer converter on that box? |
| 09:46 | <annevk> | and that the OS no longer needs to have printer support |
| 09:46 | <hsivonen> | and make the Chrome OS machine send a PDF via IPP to that box? |
| 09:46 | <hsivonen> | annevk: will they have some kind of generic HTTP to USB bridge on the intermediate box? |
| 09:47 | <hsivonen> | so that Google's cloud can talk what needs to travel over the last USB hop? |
| 09:47 | <annevk> | it prolly runs some exe file I suppose that gets info from the cloud software about what needs to happen |
| 09:47 | <annevk> | i.e. the same kind of software "cloud printers" would have |
| 09:48 | <hsivonen> | I though the IPP was supposed to solve this already |
| 09:48 | <hsivonen> | though I'm not sure if it really does |
| 09:50 | <annevk> | dunno, would love to know more |
| 11:47 | <zcorpan> | are subtitles ever streamed? |
| 11:48 | <hsivonen> | zcorpan: presumably they could if a TimBL presentation at TPAC were published as video and the captioner manages to keep up |
| 11:49 | <hsivonen> | zcorpan: the W3C has previously published live audio and live captioning of the audio as separate resources |
| 11:49 | virtuelv | has seen real-time caqtioning once |
| 11:49 | <virtuelv> | it's disturbing |
| 11:50 | <hsivonen> | in the U.S. CNN has live captioning |
| 11:50 | <virtuelv> | mostly because I consider live-captioning to be a superhuman feat |
| 11:50 | <hsivonen> | I wonder how live captioners and court reporters deal with RSI |
| 11:51 | <zcorpan> | i guess you could make real-time captioning less disturbing by delaying the video and audio the same amount of time it takes for the captioner to type a line |
| 12:32 | <nessy> | real-time captioners deal with it the same way that real-time signers do or real-time translaters |
| 12:32 | <nessy> | always have a second person as backup that can take over from you |
| 12:35 | <zcorpan> | that doesn't solve the latency problem, only the gotta-pee problem |
| 14:40 | <zcorpan> | Hixie: hmm, shouldn't we have a frame type that has no length for keep-alive purposes? currently a keep-alive frame would need two bytes (unless you keep a binary frame open and end it when you want to send a real message) |
| 14:41 | <zcorpan> | (like 0x80 .... 0x80 .... 0x80 .... 0x00 0x00 message 0xFF) |
| 14:45 | <zcorpan> | though maybe it doesn't matter if keep-alive frames are 1 byte or 2 bytes or 10 bytes |
| 14:45 | <Dashiva> | I would agree |
| 14:50 | <zcorpan> | although i quite like the idea of abusing the length bytes of a binary frame :) |
| 14:50 | <Philip`> | Keepalives have got to do a whole TCP packet or two anyway, so I don't think one byte is really worth worrying about |
| 14:51 | <zcorpan> | yeah |
| 15:06 | <boblet> | anyone have a decent (chunky) dictionary on hand? I’d like to know how it formats example sentences/phrases |
| 15:28 | <JonathanNeal> | morning all |
| 15:30 | <boblet> | hey Jon |
| 16:31 | <JonathanNeal> | datalist has been dropped from the spec? |
| 16:43 | <zcorpan> | no |
| 18:54 | <micheil> | Anyone got a forward-to for MikeSmith? |
| 18:54 | <micheil> | (the (tm) variant) |
| 19:16 | <estellevw> | is there an explanation in the spec on the attribute values of the href attribute of <a>. For example, mailto: links? |
| 19:17 | <TabAtkins> | That just depends on the scheme of the url. The schemes are all defined in various other specs. |
| 19:24 | <estellevw> | do you know where I might find it? |
| 19:24 | <estellevw> | and would it make sense to include it within the HTML5 spec? |
| 19:24 | <TabAtkins> | I'd search for "mailto scheme rfc". No idea which of the results are canonical. |
| 19:25 | <TabAtkins> | And, frankly, probably yes, but we've so far tried not to define too much what a url means (just how to decompose it, etc.) for political reasons. |
| 19:26 | <TabAtkins> | We've got some Issues active that are trying to remove more of our definitions of urls, and instead defer to other specs. |
| 19:27 | <estellevw> | ok, so i won't file a bug for it ;) I do think mailto:, tel: and others should be defined in the spec, but would rather see the spec approved :D |
| 19:28 | <estellevw> | defering to wikiipedia over the spec just seems odd |
| 19:45 | <AryehGregor> | Who's deferring to Wikipedia over the spec? |
| 19:45 | <AryehGregor> | There are specs for all these, somewhere. |
| 19:45 | <AryehGregor> | Probably. |
| 20:21 | <Hixie> | the definitions of schemes is in an iana registry |
| 21:09 | <TabAtkins> | Hixie: I changed a single word in the first paragraph of that clause, from SHOULD to MUST, and then added a non-normative note. How can that possibly weaken anything? |
| 21:10 | <Hixie> | huh. the way you added the note made me interpret "same input" differently. |
| 21:11 | <TabAtkins> | That just means you have to define "same input" more precisely. ^^_ |
| 21:11 | <Hixie> | indeed |
| 21:11 | <Hixie> | i hadn't realised that might have been a source of the confusion |
| 21:11 | <TabAtkins> | I'll cancel the email I was about to send and let you correct yourself. |
| 21:11 | <Hixie> | heh |
| 21:12 | <JonathanNeal> | Did we settle on @alt? |
| 21:13 | <TabAtkins> | No, I'm still talking with one of our internal teams. |
| 21:13 | <TabAtkins> | Dude, it's been less than 24 hours. ^_^ |
| 21:30 | <AryehGregor> | "I do not think a tautology machine would be a meaningful fulfillment of this success criterion." |
| 21:30 | <TabAtkins> | We should ask the tautology machine for confirmation. |
| 21:38 | <othermaciej> | AryehGregor: I said that weeks ago! |
| 21:38 | <othermaciej> | did it become relevant again all of a sudden? |
| 21:38 | <AryehGregor> | othermaciej, yes, I'm catching up. |
| 21:38 | <AryehGregor> | No, I just started reading the backlog. |
| 21:39 | <AryehGregor> | Got totally messed up by Passover. 250ish spec mails and >500 MediaWiki commit mails. |
| 21:42 | <Hixie> | what happened to the wiki |
| 21:44 | <AryehGregor> | Hmm. |
| 21:44 | <Hixie> | hey, there's a mediawiki person here! how convenient :-P |
| 21:44 | <Hixie> | any idea what i should do? |
| 21:45 | <AryehGregor> | I have shell access as the wiki user, so, I'm looking. :P |
| 21:45 | <AryehGregor> | (someone gave it to me, can't remember who) |
| 21:45 | <AryehGregor> | Looks like a DB problem to me, not a MW problem. |
| 21:45 | <AryehGregor> | But let me see. |
| 21:45 | <Hixie> | well you have access to the db too if you have access to the shell :-P |
| 21:45 | <AryehGregor> | Yep. |
| 21:45 | <Hixie> | time for me to start changing passwords i guess :-P |
| 21:46 | <Hixie> | (i'm fine with you having access, but, um, people, please let me know who you give access to :-P ) |
| 21:46 | <AryehGregor> | Interesting. |
| 21:47 | <AryehGregor> | Maybe it is a MediaWiki problem. |
| 21:47 | <AryehGregor> | Let me see if setting $wgCacheDirectory fixes it. |
| 21:48 | <Hixie> | i hope it was Lachy_ who gave you access |
| 21:49 | <AryehGregor> | There we go, fixed. |
| 21:49 | <AryehGregor> | Apparently the new localization cache system isn't too reliable if you use a database backend. |
| 21:49 | <Hixie> | good to know |
| 21:49 | <AryehGregor> | It's meant to use a filesystem-based cache, I think CDB or something. |
| 21:50 | <AryehGregor> | You can chown /home/whatwikiuser/wikicache to be webserver-writable but not world-writable, if you like (I just set 777). |
| 21:50 | <AryehGregor> | (since, obviously, I can't do anything else) |
| 21:52 | <Hixie> | the server runs as the user |
| 21:52 | <AryehGregor> | Oh, mod_cgi? |
| 21:52 | <AryehGregor> | Okay. |
| 21:53 | <Hixie> | yeah |
| 21:53 | <Hixie> | should do anyway |
| 21:53 | <AryehGregor> | Yeah, I see that now. |
| 21:57 | <Hixie> | thanks for fixing it btw! much appreciated |
| 21:57 | <Hixie> | dunno what i would have done :-P |
| 21:57 | <AryehGregor> | You could have asked for help in #mediawiki! |
| 21:57 | <AryehGregor> | (although you probably wouldn't be running unreleased versions, so you probably wouldn't have hit the problem) |
| 23:02 | <AryehGregor> | Is there a site that lets you sketch something in a <canvas> (not Flash) and then saves it so you can share the URL, pastebin-style? |
| 23:04 | <Dashiva> | Are you looking for the existence of such a site, or do you just want to share the results of a canvas drawing? |
| 23:04 | <othermaciej> | http://mugtug.com/sketchpad/ |
| 23:04 | <othermaciej> | ? |
| 23:04 | <Steve^> | If this works, then yes: http://tinyurl.com/y5ybzlm |
| 23:04 | <AryehGregor> | Oh, cosketch.com actually seems to use canvas. Interesting. |
| 23:04 | <Steve^> | translates to some data: thing |
| 23:04 | <AryehGregor> | I wanted to share the results of a quick sketch easily. |
| 23:04 | <othermaciej> | that data: URL didn't load for me |
| 23:04 | <AryehGregor> | I want it to use canvas because I have Flash disabled in my primary browser. |
| 23:05 | <Steve^> | I did that with the same link othermaciej mentioned |
| 23:05 | <Dashiva> | That URL looks broken, yes |
| 23:05 | <AryehGregor> | Didn't work for me either. |
| 23:05 | <AryehGregor> | Maybe it's truncated? |
| 23:05 | <Steve^> | opens in Opera, at least |
| 23:05 | <Steve^> | ooo, now it doesn't |
| 23:05 | <Steve^> | must have been a cached version |
| 23:05 | <Dashiva> | It opens, but the image is messed up |
| 23:05 | <othermaciej> | Steve^: odd, the data: URL works right from the web app, but not via bit.ly |
| 23:05 | <othermaciej> | er, via tinyurl |
| 23:06 | <othermaciej> | I think tinyurl may be cutting off the URL |
| 23:06 | <Steve^> | yea, maybe another shortener will be better |
| 23:06 | <othermaciej> | you can also draw with Sketchpad, copy the image local, and them upload to http://imgur.com/ |
| 23:06 | <Steve^> | how would you save it locally? |
| 23:07 | <othermaciej> | drag & drop after clicking the save button |
| 23:07 | <othermaciej> | or use Save As... from the browser File menu after clicking save |
| 23:08 | <Dashiva> | Ideally the browser would let you do save as... directly on a canvas, but it doesn't seem to be high priority |
| 23:09 | <AryehGregor> | Copying locally is too annoying. I could do it in the GIMP if I wanted to do that. |
| 23:09 | <Steve^> | indeed |
| 23:10 | <othermaciej> | sketchpad with a built in image hosting service would be really sweet |
| 23:10 | <AryehGregor> | Although a web page would probably load a lot faster than the GIMP. |
| 23:10 | <othermaciej> | looks like they may be vaguely planning that |
| 23:23 | <AryehGregor> | Haha: http://arewefastyet.com/ |
| 23:24 | <AryehGregor> | Why are V8 and Nitro so close there? Because it's not mostly raw JS performance, or what? |
| 23:24 | AryehGregor | also wonders if they're testing against Chromium/WebKit trunk, or a release |
| 23:24 | AryehGregor | likes the "NO" |
| 23:33 | <othermaciej> | AryehGregor: V8 and Nitro are fairly similar designs, though I am surprised at how close they are on that diagram |
| 23:43 | <dglazkov> | hey, brain people. especiallly TabAtkins |
| 23:43 | <dglazkov> | :P |
| 23:44 | <dglazkov> | can someone point me to a place that specifies submit-on-enter behavior for forms? I've been looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#forms and can't spot it |
| 23:45 | <dglazkov> | in other words, in which cases does hitting an enter in a textfield could submit a form? |
| 23:45 | <dglazkov> | IE and FF seem to agree that only if there's one text area and no submit button in the form. |
| 23:45 | <dglazkov> | WebKit just does it if there's no submit button. |
| 23:45 | <dglazkov> | either behavior seems arbitrary and weird. |
| 23:45 | <Hixie> | search for "default button" or some such |
| 23:46 | <Hixie> | or "default submit button" |
| 23:47 | <othermaciej> | dglazkov: seems like "enter" in a form should always activate the default button for the form (or submit if there isn't one) |
| 23:47 | <othermaciej> | dglazkov: "enter" in a text field in a form, rather |
| 23:47 | <othermaciej> | and perhaps also other controls when focused |
| 23:48 | <othermaciej> | dglazkov: seems like this is also more a UI issue than an interop issue - it might be irrelevant on platforms with a virtual keyboard that doesn't have "enter" when editing a text field for instance |
| 23:48 | <dglazkov> | othermaciej: try https://bug-21716-attachments.webkit.org/attachment.cgi?id=24462 in FF or WebKit. |
| 23:49 | <othermaciej> | dglazkov: in Safari/Mac + ToT WebKit pressing enter submits the form |
| 23:49 | <TabAtkins> | dglazkov: You want section 4.10.21.2 |
| 23:49 | <dglazkov> | othermaciej: yep. |
| 23:49 | <Hixie> | right, what TabAtkins said |
| 23:49 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/complete.html#implicit-submission |
| 23:49 | <othermaciej> | is that a bad thing? |
| 23:50 | <Hixie> | dglazkov: the spec covers that test case with no ambiguity |
| 23:50 | <TabAtkins> | No ambiguity, but with some leeway for UAs to do what they want. |
| 23:50 | <Hixie> | and says firefox is buggy |
| 23:50 | <Hixie> | no, not that test case |
| 23:51 | <TabAtkins> | Ah, right, true. |
| 23:51 | <Hixie> | there's no button, so it's pretty strictly defined |
| 23:51 | <TabAtkins> | Yes. |
| 23:51 | <TabAtkins> | Since FF does have an implicit submission method, there are some MUSTs it has to follow there. |
| 23:52 | <dglazkov> | so IE and FF are both wrong then? |
| 23:52 | <dglazkov> | and Opera too |
| 23:54 | <dglazkov> | when only one browser gets the spec right, is it: a) awesome b) horrifying or c) ain't right? |
| 23:55 | <TabAtkins> | Depends on the feature. ^_^ |
| 23:57 | <TabAtkins> | dglazkov: What behavior are you seeing in FF that makes you think its buggy? FF submits a form with or without a submit button when you hit enter in a text input. |
| 23:57 | <TabAtkins> | That appears to be exactly what the spec says. |
| 23:58 | <jcranmer> | hmm, judging from roc's latest post, it seems like the worries about hardware decoding for theora are overblown |
| 23:59 | <othermaciej> | dglazkov: it seems like hitting Enter in a text input should pretty much always submit the form, unless some key event handler would prevent that |
| 23:59 | <othermaciej> | dglazkov: do you think that is wrong for some reason? are there any sites that rely on sometimes not submitting in that case? |