| 00:00 | <Philip`> | zcorpan_: Maybe those people or the people they got the original data from would be willing to share the original data if asked |
| 00:00 | Philip` | was unable to easily find easily-downloadable subtitle collections |
| 00:01 | <Philip`> | (which I guess is because the people who collect the subtitles want to show loads of adverts to visitors, and don't want other sites copying all the data they've collected from volunteers) |
| 00:03 | <zcorpan_> | it says source: http://www.opensubtitles.org |
| 00:10 | <zcorpan_> | Hixie: the first random srt i download has <i> wrapping multiple lines |
| 00:10 | <zcorpan_> | (well, the second random. the first didn't have any markup) |
| 00:11 | <zcorpan_> | http://www.opensubtitles.org/en/download/sub/3695049 |
| 00:11 | <zcorpan_> | i have no idea which encoding that one is using |
| 00:13 | <Hixie> | zcorpan_: ah, excellent, good to know, thanks |
| 00:18 | <zcorpan_> | it seems existing srts use different legacy encodings and don't declare it :( |
| 00:19 | <variable> | Has there been any discussion on client side includes for HTML files? |
| 00:19 | <roc> | yes |
| 00:19 | <roc> | see if <iframe seamless> is what you want |
| 00:22 | <variable> | the spec is the only document that has more links to itself than wikipedia ;) |
| 00:24 | <zcorpan_> | i wonder what to do about the encoding issue |
| 00:25 | <variable> | roc, as I read the spec "seamless" means that <html>___stuff___</html> is the same as <html><iframe srcdoc="____stuff____" seamless></html> - am I correct ? |
| 00:25 | <zcorpan_> | hopefully people will reencode their legacy subtitles to utf-8 for web use |
| 00:25 | <variable> | (or src="document" where document has ___stuff___ in it) |
| 00:25 | <AryehGregor> | variable, no, it's radically different in lots of ways. |
| 00:25 | <AryehGregor> | However, it should be similar enough for most purposes. |
| 00:26 | <roc> | what Aryeh said |
| 00:26 | <variable> | AryehGregor, can you explain? I'm not /that/ knolegeable. |
| 00:26 | <AryehGregor> | Well, it's an iframe. |
| 00:26 | <variable> | *not that familier with how it works |
| 00:26 | <AryehGregor> | It integrates better than a regular iframe, but still an iframe. |
| 00:26 | <AryehGregor> | So there's a whole separate document inside. |
| 00:27 | <AryehGregor> | But you can make it blend in to the bigger document visually, etc. |
| 00:27 | <roc> | it's a separate document, it's in a rectangle |
| 00:27 | <variable> | AryehGregor, in a seamless iframe is top.location == location ? |
| 00:27 | <roc> | for example you can't expect to put inline content in it and wrap that content at line breaks |
| 00:27 | <roc> | it has its own DOM |
| 00:27 | <roc> | its top.location != location in general |
| 00:28 | <variable> | so what does "When specified, it indicates that the iframe element's browsing context is to be rendered in a manner that makes it appear to be part of the containing document (seamlessly included in the parent document). " |
| 00:28 | <variable> | mean? or can you point me to some "newbie" docs the issue? |
| 00:29 | <TabAtkins> | It means that it should look like the <iframe> tag wasn't there at all. |
| 00:30 | <TabAtkins> | (Replaced by the contents of the contained document.) |
| 00:30 | <variable> | so to the enclosing page there is no iframe but to the iframe content it is on its own |
| 00:31 | variable | has to learn how to read the spec better |
| 00:31 | <TabAtkins> | Visually, yes. In all other respects, the <iframe> is still there and acts normally. |
| 00:31 | <variable> | Ah. I see. |
| 00:31 | <variable> | There is no "client side include" but you can get the visual effect. OK |
| 00:32 | <TabAtkins> | Yeah. |
| 00:32 | <TabAtkins> | Actualy client-side includes have to be faked with javascript and xhr. |
| 00:32 | <TabAtkins> | s/Actualy/Actual/ |
| 00:32 | <variable> | ok. good to know |
| 00:35 | zcorpan_ | finds an srt with Traducerea ∫i adaptarea: <font color=#ff99cc>Kprice</font> |
| 00:35 | zcorpan_ | <font color=#ffffff>Subtitr„ri-Noi Team</font> |
| 00:36 | <TabAtkins> | Is that an integral sign? |
| 00:36 | <variable> | TabAtkins, yes |
| 00:36 | <zcorpan_> | wrong encoding |
| 01:50 | <MikeSmith> | um |
| 01:51 | <MikeSmith> | how is the word "activateable" spelled? |
| 01:51 | <MikeSmith> | is that not a word? |
| 01:54 | <MikeSmith> | activatable |
| 01:54 | <MikeSmith> | only ~100,000 ocurrances |
| 01:55 | MikeSmith | wonders what other ways people use to express the "activatable" |
| 01:57 | <Philip`> | "can be activated" |
| 01:58 | <MikeSmith> | Philip`: my context is, "Make drag-and-drop events keyboard-activatable" |
| 01:59 | <MikeSmith> | is "Make drag-and-drop events fireable by keyboard" any better? |
| 01:59 | <MikeSmith> | you don't really "activate" an event, anyway |
| 02:00 | <Philip`> | "Allow keyboard activation of drag-and-drop events" |
| 02:02 | <MikeSmith> | thanks |
| 02:07 | <MikeSmith> | Hixie: when you have a chance, please flip the spec back to ED |
| 02:08 | <Hixie> | k |
| 02:08 | <MikeSmith> | thanks |
| 02:17 | <Hixie> | remind me if i forget to do it in the next few hours |
| 02:30 | <MikeSmith> | man, David Carlisle is a model of how inter-WG problem-resolving should be conducted |
| 02:30 | <MikeSmith> | despite me talking trash about my frustrations with MathML stuff, he always remains gracious |
| 02:31 | <MikeSmith> | and focuses on trying to figure out where the problems are and how we can try to fix them |
| 02:32 | <nessy> | it can be hard - keeping feelings under control is always hard - but it's definitely more productive ;) |
| 02:32 | <MikeSmith> | yep |
| 02:37 | <MikeSmith> | Hixie: if/when you might find some real-time discussion with David to be useful, he says feel free to e-mail or skype him and he can join the channel for the discussion |
| 02:39 | <MikeSmith> | hmm, I find a David Carlisle whose Skype handle is "abadassmother" |
| 02:39 | <MikeSmith> | somehow I think that's not likely him |
| 02:40 | <AryehGregor> | See, that's the nice thing about having a distinctive name. No confusion necessary. |
| 02:40 | <AryehGregor> | (I assume you could tell us the opposite end of that story.) |
| 02:41 | <MikeSmith> | heh |
| 02:41 | <AryehGregor> | No other Mike Smith had the foresight to trademark their name, though. That's how I was able to find you on Twitter or something one time. |
| 02:42 | <MikeSmith> | I'm trademarking the fact that I have a trademark in my name |
| 02:42 | MikeSmith | looks for Aryeh on twitter |
| 02:42 | <AryehGregor> | Good luck. |
| 02:43 | AryehGregor | uses no social networking site or anything vaguely similar. |
| 02:43 | <AryehGregor> | Well, I guess I technically use Google Buzz, but only because I wasn't given a choice. |
| 02:43 | <MikeSmith> | heh |
| 02:43 | <AryehGregor> | (I don't post to it, in my defense) |
| 02:43 | <MikeSmith> | that's the next step in their plan |
| 02:43 | <AryehGregor> | (Nor does anyone else in the universe, though, except TabAtkins) |
| 02:44 | <AryehGregor> | (and possibly a single-digit number of other Google employees) |
| 02:44 | <MikeSmith> | I hear Buzz2 will actually generate posts without your consent, and send them out to all your contacts automatically, with them all Cc'ed so that they know who each other are (of course) |
| 02:45 | <MikeSmith> | so that'll be a nice feature to have |
| 02:45 | <AryehGregor> | Even better than what I've heard about Facebook! |
| 02:45 | <MikeSmith> | they will call it a feature for "lazy bloggers who have anxiety about not having posted for 3 months" |
| 02:46 | <MikeSmith> | Facebook is the market leader in privacy-infringing special features |
| 02:46 | <MikeSmith> | they are setting the de facto standards |
| 02:46 | <AryehGregor> | Yes, but Google is in a strong position to overtake them if they put their mind to it. |
| 02:46 | <MikeSmith> | yes |
| 02:46 | <AryehGregor> | I mean, where was Facebook when Google was out collecting people's unsecured Wi-Fi data without telling them? |
| 02:47 | <MikeSmith> | they just need to try harder, find more novel ways to expose people's private info |
| 02:47 | <MikeSmith> | AryehGregor: good point |
| 02:47 | <MikeSmith> | Google should blog about that |
| 02:47 | <MikeSmith> | "Nobody can infringe on privacy at the scale we can!" |
| 02:48 | <AryehGregor> | They do have an effective opt-out program, to be fair. http://www.theonion.com/video/google-opt-out-feature-lets-users-protect-privacy,14358/ |
| 02:49 | <AryehGregor> | The video doesn't work for me. :( |
| 03:01 | <MikeSmith> | "The Opt-Out Village" |
| 03:02 | <MikeSmith> | beautiful |
| 03:02 | <MikeSmith> | "Christian Groups: Biblical Armageddon Must Be Taught Alongside Global Warming" is nice too |
| 03:06 | <othermaciej> | MikeSmith: that's good to hear, about David Carlisle |
| 03:27 | <MikeSmith> | othermaciej: yeah, kind of leading by example |
| 08:00 | <MikeSmith> | I wonder if Chris Grigg in the Audio XG is the same as the one who was a member of Negativland |
| 08:01 | <MikeSmith> | ...and who also maybe the same who wrote the music for Maniac Mansion |
| 08:12 | <MikeSmith> | is there any way in MediaWiki to add an ID to a paragraph or term/span of text or whatever? |
| 08:14 | <annevk> | http://www.w3.org/QA/2010/06/an_update_on_css_21.html |
| 08:18 | <MikeSmith> | somebody posted a comment to that blog entry but it has not appeared yet for some reason |
| 08:18 | <MikeSmith> | though I got an feed notification about it |
| 08:44 | <MikeSmith> | https://bugs.webkit.org/show_bug.cgi?id=41363 is interesting |
| 08:44 | <MikeSmith> | what to do if author puts "body { text-rendering: optimizeLegibility; }" |
| 08:45 | <MikeSmith> | paul_irish: btw, I don't think putting fragment IDs onto shortened URLs works the way you might have intended :) |
| 08:46 | <MikeSmith> | e.g., http://webk.it/6136#c3 |
| 08:46 | Hixie | mumbles something about it being bad to give authors control over how UAs optimise |
| 08:46 | <MikeSmith> | what to do if author puts "body { text-rendering: optimizeEntireBrowsingExperience; }" |
| 08:47 | <Peter`> | MikeSmith: Chrome forwards me to https://bugs.webkit.org/show_bug.cgi?id=6136#c3, also scrolls the page to the intended position |
| 08:47 | <MikeSmith> | Peter`: well lah dee dah |
| 08:47 | <MikeSmith> | good for you |
| 08:47 | <MikeSmith> | seriously? |
| 08:47 | <Peter`> | Uh..? |
| 08:47 | <MikeSmith> | does Chrome cook breakfast for people now too? |
| 08:48 | <MikeSmith> | it seems like chrome should not do that |
| 08:48 | <hsivonen> | I'm concerned of a situation where a perf test suite turns on all these typographic nice things but doesn't test that they are taking effect and then Brand X browser scores better than Gecko simply by not implementing any of that stuff |
| 08:49 | <Peter`> | Whatever. I'm just saying it works on Chrome, I'm unaware of what the spec says on it, or of what other browsers do. |
| 08:49 | <Lachy> | MikeSmith, I just tried to update my answer on the issue 88 objetion poll, but it doesn't seem to be accepting my changes. It's still showing my original answers. |
| 08:49 | <MikeSmith> | Lachy: I'll check now |
| 08:50 | <hsivonen> | Lachy: do you see the new answer in another browser? |
| 08:50 | <MikeSmith> | Peter`: sorry, I was just trying to be funny, but I guess it sounded like I was trying to be a dick instead.. |
| 08:51 | <Lachy> | ah, yeah, it works now. Must have been just a cache issue. |
| 08:51 | <Peter`> | Ok, I misinterpreted your message in that case, thank you for clearing it up |
| 08:52 | <MikeSmith> | Peter`: hmm, Minefield and Opera also do as Chrome does for http://webk.it/6136#c3 .. so egg on my face |
| 08:52 | <MikeSmith> | Safari does not, though |
| 08:52 | <MikeSmith> | or at least Webkit does not |
| 08:52 | <MikeSmith> | nightly |
| 08:52 | <Peter`> | IE doesn't do it either |
| 08:52 | <MikeSmith> | interesting |
| 08:53 | <MikeSmith> | I wonder what the specs say |
| 08:53 | <Hixie> | 20 hours left on the polls, Philip`, zcorpan, MikeSmith, and anyone else i missed :-) |
| 08:54 | <Hixie> | foolip: ^ |
| 08:54 | <MikeSmith> | I payed at the office. |
| 08:55 | <MikeSmith> | Lachy: OK. I have noticed some other unusualities lately that seem to indicate borked caching somewhere |
| 08:55 | <Peter`> | MikeSmith: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43 seems to be related |
| 08:55 | <annevk> | MikeSmith, fragids ought to be forwarded |
| 08:55 | <MikeSmith> | Peter`: thanks |
| 08:55 | MikeSmith | reads |
| 08:55 | <annevk> | MikeSmith, though client-side |
| 08:55 | <Peter`> | while it more specifically relates to overriding fragment ids |
| 08:56 | <MikeSmith> | annevk: sez who? |
| 08:56 | <annevk> | MikeSmith, it's like <image> needs to be parsed as <img>; it wasn't always defined, but it's certainly true :p |
| 08:56 | <annevk> | MikeSmith, I believe the HTTP WG might catch up though |
| 08:57 | <annevk> | MikeSmith, actually, I think it has always been defined for the simple case |
| 08:59 | <annevk> | MikeSmith, maybe not, "fragment" is mentioned only once in 2616 (haven't looked at errata though) |
| 09:00 | <Peter`> | http://www.w3.org/Protocols/HTTP/Fragment/draft-bos-http-redirect-00.txt |
| 09:00 | <Peter`> | That seems to be spot-on |
| 09:01 | <annevk> | no official standing whatsoever though |
| 09:01 | <annevk> | so I guess it's like <image> after all |
| 09:02 | <MikeSmith> | good times |
| 09:05 | <hsivonen> | Hixie: I'm debugging an interesting crash with document.documentElement.innerHTML = "<math></html>" |
| 09:06 | <hsivonen> | Hixie: I think the spec doesn't take this into account, and my ad hoc fixes to the spec don't take it into account, either |
| 09:08 | <foolip> | ddfdf |
| 09:08 | <annevk> | one more and you have a color |
| 09:08 | <foolip> | hehe |
| 09:10 | <foolip> | just trying to shut things down, this computer i moving to Gothenburg |
| 09:11 | <hsivonen> | Hixie: I assume we wouldn't want to switch out of 'in foreign' and into 'after body' with <math> on the top of the stack |
| 09:12 | <annevk> | the spec doesn't crash though, does it? |
| 09:13 | <zcorpan_> | https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=559531 - IE9 fails html5lib html parser tests - Closed |
| 09:13 | <zcorpan_> | as Fixed |
| 09:14 | <hsivonen> | Hixie: OTOH, if we don't (or only change the secondary mode to 'after body'), the end tag handling in 'in foreign content' ends up popping <html> off the stack |
| 09:15 | <hsivonen> | which should never happen and, therefore, crashes in EOF handler |
| 09:17 | <jgraham> | hsivonen: Would it be possible for you to document your ad-hoc fixes to the spec in the relevant bug reports? |
| 09:17 | <hsivonen> | jgraham: I suppose it would be possible |
| 09:18 | <jgraham> | hsivonen: Prose is easier to read than java :) |
| 09:18 | <zcorpan_> | seems they still fail many html5lib tests |
| 09:18 | <annevk> | hsivonen, so it doesn't crash for <math></head> or <math></body> or <math></td> ? |
| 09:19 | <hsivonen> | annevk: let's check |
| 09:19 | <hsivonen> | annevk: no crash |
| 09:20 | <hsivonen> | annevk: (with html as the context node) |
| 09:20 | <hsivonen> | so it seems wrong to change the primary mode to 'after body' without popping the foreign stuff off the stack |
| 09:21 | <hsivonen> | I think this leaves three options: |
| 09:21 | <hsivonen> | 1) Ignoring </html> (and maybe </body>) in 'in foreign content' |
| 09:21 | <hsivonen> | 2) popping all foreign stuff off the stack when transitioning to 'after body' |
| 09:22 | <hsivonen> | 3) making an exception in the end tag handling in 'in foreign' so that the first item on the stack never gets popped no matter what |
| 09:22 | <jgraham> | hsivonen: It feels like </html> in innderHTML should be ignored |
| 09:22 | <annevk> | is this specific to in foreign content or would a document <math></html> do it too? |
| 09:22 | <jgraham> | Although I don't know what happens in other cases |
| 09:22 | <MikeSmith> | zcorpan_: are there bugs open for the other tests they fail? |
| 09:23 | <MikeSmith> | zcorpan_: or is their any distinguishable pattern to the bugs they fail? |
| 09:23 | <zcorpan_> | ie breaks out of <mtext> |
| 09:23 | <hsivonen> | annevk: <math></html> crashes even without fragment mode |
| 09:23 | <MikeSmith> | zcorpan_: hmm, that especially ain't good |
| 09:23 | <zcorpan_> | MikeSmith: no (afaik) and no (they just fail lots of tests) |
| 09:23 | <MikeSmith> | k |
| 09:24 | <hsivonen> | jgraham: so ignoring </html> in the fragment case is not the right fix |
| 09:24 | <zcorpan_> | oh they don't support mathml parsing at all |
| 09:24 | <zcorpan_> | and i was using <svg>, heh |
| 09:25 | <zcorpan_> | hmm they don't do case fixup for <foreigncontent> |
| 09:25 | <jgraham> | hsivonen: Well, it might be part of the right fix :) |
| 09:26 | <zcorpan_> | but they break out of <foreignContent> |
| 09:26 | <annevk> | hsivonen, and it's due to the spec? still not quite clear to me where it goes wrong; but I guess I should do something else |
| 09:26 | <jgraham> | annevk: The spec for end tag handling in foreign content mode is broken on its own |
| 09:26 | <hsivonen> | annevk: it is possible that my ad hoc fixes to spec crashes introduced this crash |
| 09:27 | <jgraham> | annevk: hsivonen has added some fixes |
| 09:27 | <hsivonen> | annevk: Hixie's fixes to SVG </a> and </font> handling caused the spec to crash |
| 09:28 | <jgraham> | hsivonen: This case crashes my local copy of html5lib which I think implements the spec as written |
| 09:28 | <zcorpan_> | at least they parse <foobar/> outside foreign content correctly now :) |
| 09:28 | <abarth> | are they trying to implement the HTML5 parsing algorithm? |
| 09:29 | <jgraham> | abarth: They seem to be trying to implement foreign content in HTML |
| 09:29 | <annevk> | I think the rest of it too |
| 09:29 | <zcorpan_> | abarth: half-assed, yes. they have a proper tree now (they said they implemented AAA) and svg in html |
| 09:29 | <jgraham> | it's not clear whether they are implementing the rest of the algorithm or trying to cherry pick |
| 09:30 | <hsivonen> | jgraham: I'm thinking of either ignoring </html> in 'in foreign content' or modifying step 3 under "An end tag, if the current node is not an element in the HTML namespace." stop right before it pops the last node off the stack |
| 09:30 | <zcorpan_> | they don't implement foster parenting |
| 09:30 | <abarth> | cherry picking seems silly |
| 09:30 | <jgraham> | abarth: Indeed |
| 09:30 | <abarth> | the main benefit is from going "all in" (to borrow a phrase from my favorite blog) |
| 09:31 | <hsivonen> | zcorpan_: interesting. I have thought that implementing parts of the parsing algorithm in an existing parser would be more painful than implementing the whole thing from scratch |
| 09:31 | <jgraham> | hsivonen: Have you made other changes to that algorithm? |
| 09:32 | <hsivonen> | jgraham: I fixed http://www.w3.org/Bugs/Public/show_bug.cgi?id=9582 , http://www.w3.org/Bugs/Public/show_bug.cgi?id=9581 and http://www.w3.org/Bugs/Public/show_bug.cgi?id=9580 |
| 09:32 | <zcorpan_> | hsivonen: maybe their goal for ie9 was just proper tree and svg support |
| 09:33 | <hsivonen> | jgraham: I'll look up my code changes and try to figure out how to map those back to English |
| 09:33 | <hsivonen> | jgraham: the diff is http://hg.mozilla.org/projects/htmlparser/rev/b08b9993cd5d |
| 09:34 | <hsivonen> | jgraham: don't pay attention to the "changes" inside switch (mode) |
| 09:35 | <jgraham> | hsivonen: thanks |
| 09:40 | <hsivonen> | jgraham: eltPosForeign represents /node/ from the spec (by index) |
| 09:40 | <hsivonen> | jgraham: the three lines at http://hg.mozilla.org/projects/htmlparser/rev/b08b9993cd5d#l1.66 are one addition |
| 09:41 | <hsivonen> | fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9580 |
| 09:42 | <hsivonen> | jgraham: http://hg.mozilla.org/projects/htmlparser/rev/b08b9993cd5d#l1.64 fixes http://www.w3.org/Bugs/Public/show_bug.cgi?id=9582 |
| 09:42 | <hsivonen> | jgraham: currentPtr is the index of the top aka. bottom of the stack |
| 09:44 | <hsivonen> | jgraham: it it is smaller than the just-decremented eltPosForeign, the secondary insertion mode has popped so much stuff that it would be bad to continue per spec before /node/ is in range for the current stack again |
| 09:45 | <hsivonen> | jgraham: the left-hand part of the |if| condition on line http://hg.mozilla.org/projects/htmlparser/rev/b08b9993cd5d#l1.57 fixes http://www.w3.org/Bugs/Public/show_bug.cgi?id=9581 |
| 09:45 | <hsivonen> | jgraham: that's all, I think |
| 09:46 | <jgraham> | hsivonen: OK |
| 09:50 | <hsivonen> | krijnh: logs are broken |
| 09:55 | <hsivonen> | zcorpan_: they aren't supposed to case-correct <foreigncontent> but <foreignobject> |
| 09:57 | <MikeSmith> | zcorpan_: what's AAA? |
| 09:58 | <annevk> | adoption-agency-algorithm |
| 09:58 | <zcorpan_> | hsivonen: oops |
| 09:58 | <MikeSmith> | ah |
| 09:58 | <hsivonen> | jgraham: currently, </body> in 'in foreign' pops more stuff than </body> with <div> but no foreign content on the stack |
| 09:59 | <hsivonen> | jgraham: I'd expect this to be a bug, too |
| 09:59 | <zcorpan_> | hsivonen: still, they didn't turn <fooBarBaz> to lowercase |
| 09:59 | <hsivonen> | what if we ignored </body> and </html> in 'in foreign content'? |
| 09:59 | <hsivonen> | would that be too blunt a solution? |
| 10:01 | zcorpan_ | wouldn't mind always ignoring </body> and </html> |
| 10:02 | <jgraham> | wfm I think |
| 10:04 | <hsivonen> | hmm. I think the new end tag handling is probably more aggressive that Hixie intended |
| 10:04 | <hsivonen> | consider <dl><svg><foreignContent><div><math></dl><foo> |
| 10:04 | <hsivonen> | </dl> pops stuff until <dl> has been popped |
| 10:04 | <hsivonen> | in particular, it doesn't stop at the <div> |
| 10:05 | <hsivonen> | aaagh. |
| 10:05 | <hsivonen> | zcorpan_'s foreignContent is messing with my head |
| 10:05 | <zcorpan_> | heh |
| 10:06 | <hsivonen> | anyway, <foo> becomes the next sibling of <dl> |
| 10:07 | <zcorpan_> | why would it stop at the div? that doesn't make any sense |
| 10:08 | <hsivonen> | in the <dl><svg><foreignObject><div><math></dl><foo> case, both <foreignObject> and <div> are scoping |
| 10:08 | <hsivonen> | normally, </dl> doesn't match a <dl> if there's a scoping element in between |
| 10:08 | <jgraham> | I agree that it should stop at scopiung elements |
| 10:09 | <jgraham> | *scoping |
| 10:09 | <zcorpan_> | if there's a scoping element in between, shouldn't the end tag just be treated as if the <dl> start tag wasn't there? |
| 10:10 | <hsivonen> | zcorpan_: possibly, but that's not what the spec does |
| 10:10 | <hsivonen> | zcorpan_: which looks like a spec bug to me |
| 10:10 | <hsivonen> | it's a bug of such magnitude that I'm not fully comfortable with improvising as solution |
| 10:11 | <hsivonen> | but I should land something to get rid of the crasher :-( |
| 10:11 | <zcorpan_> | <dl><div></dl>x |
| 10:11 | <zcorpan_> | closes the dl |
| 10:12 | <hsivonen> | zcorpan_: good point |
| 10:12 | <hsivonen> | <dl><div></body>x |
| 10:13 | <hsivonen> | doesn't close dl |
| 10:13 | <hsivonen> | but if </body> happens in 'in foreign' it pops stuff all the way to <body> |
| 10:14 | <hsivonen> | well, I guess ignoring </body> and </html> would good enough to address the worst cases |
| 10:16 | <MikeSmith> | . |
| 10:16 | <MikeSmith> | (sorry, fat-finger) |
| 10:17 | <hsivonen> | whoa. <dl><svg><foreignObject><div><math></body><foo> is worse than I thought |
| 10:17 | <hsivonen> | <foo> becomes the next sibling on <body>! |
| 10:19 | <MikeSmith> | sweet |
| 10:20 | <MikeSmith> | huh? |
| 10:20 | <MikeSmith> | isn't already the next sibling of body in your example? |
| 10:21 | <MikeSmith> | oh |
| 10:21 | MikeSmith | puts down his meth pipe |
| 10:21 | <MikeSmith> | (ignore me) |
| 10:26 | <zcorpan_> | awesome that websrt has <comment> and ie also has <comment> in html |
| 10:28 | <jgraham> | hsivonen: I think the end tag handling in In Foreign Content needs to be totally rewritten... |
| 10:29 | <hsivonen> | jgraham: :-( |
| 10:29 | <hsivonen> | jgraham: how? |
| 10:30 | <hsivonen> | is the whatwg wiki broken or my browser? some operations that are supposed to redirect me don't |
| 10:30 | <hsivonen> | and I'm left with a blank page |
| 10:30 | <jgraham> | hsivonen: I don't know |
| 10:30 | <jgraham> | hsivonen: That's the problem |
| 10:31 | <jgraham> | But it feels like we're trying to patch around the wrong approach |
| 10:31 | <jgraham> | I could be wrong of course |
| 10:33 | <hsivonen> | jgraham: it's also possible that my fix for http://www.w3.org/Bugs/Public/show_bug.cgi?id=9582 is wrong |
| 10:33 | <annevk> | http://html5.org/tools/web-apps-tracker now remembers the show editorial flag |
| 10:34 | <hsivonen> | jgraham: and the right fix would be setting the insertion mode to the secondary mode and returning instead of continuing the loop |
| 10:35 | <annevk> | only browser it goes wrong in is Firefox |
| 10:35 | <annevk> | it does not seem to reflow the page after a class name change to the body element |
| 10:36 | <zcorpan_> | annevk: nice |
| 10:41 | <roc> | looks to me like the body class is not being set in firefox |
| 10:42 | <zcorpan_> | http://forums.whatwg.org/viewtopic.php?t=4334 - how to produce HTML5 printable pdf |
| 10:43 | <annevk> | roc, weird, everyone gets the same code |
| 10:43 | <annevk> | roc, and invoking updateEditorial() after page load does work... |
| 10:44 | <annevk> | roc, maybe a bug due to parser changes? |
| 10:44 | <roc> | checking |
| 10:45 | <roc> | so I think it's to do with form history restoration |
| 10:46 | <hsivonen> | does it involve innerHTML? |
| 10:46 | <roc> | no |
| 10:46 | <hsivonen> | good |
| 10:46 | <roc> | if you load the page the first time, the checkbox is checked. You uncheck the checkbox and reload. We remember that the checkbox was unchecked, so in the reloaded page, we uncheck it |
| 10:46 | <roc> | then "if(showEdits() && readCookie("editorial") == "editorial") {" is false because showEdits returned false because the editorial checkbox is not checked |
| 10:47 | <roc> | so you don't call updateEditorial |
| 10:48 | <jgraham> | hsivonen: So am I reading your fixes right? If I am they boil down to: |
| 10:48 | <jgraham> | In step 4 abort if node is the root node |
| 10:49 | <jgraham> | After step 5, if node is no longer on the stack of open elements, set node to the bottommost element on the stack of open elements |
| 10:49 | <annevk> | roc, ah, you remember the value of the checkbox, but not the class name on the body |
| 10:49 | <roc> | yeah |
| 10:49 | <annevk> | hmm |
| 10:49 | <roc> | why would we remember the class name on the body? |
| 10:51 | <annevk> | mkay, removed the showEdits() check there |
| 10:51 | <annevk> | went wrong in Chrome too with history navigation |
| 10:51 | <annevk> | Opera works fine |
| 10:52 | <roc> | I'm not really sure what the status of form history restoration is |
| 10:52 | <roc> | spec-wise |
| 10:58 | <annevk> | I think Hixie might have specced it out, but I'm not familiar with the details |
| 10:59 | <roc> | annevk: I'm confused about one thing in your page |
| 10:59 | <roc> | function updateEditorial() { |
| 10:59 | <roc> | var editorial = showEdits() ? "" : "editorial" |
| 10:59 | <roc> | shouldn't that be the other way around? |
| 11:00 | <annevk> | the naming is all confusing :/ |
| 11:00 | <annevk> | but editorial means that stuff will be hidden |
| 11:00 | <annevk> | well "editorial" |
| 11:01 | <hsivonen> | yeah, the YouTube blog *so* makes me want to support Content Protection to enable them to serve "This rental is currently unavailable in your country." |
| 11:01 | <annevk> | this code needs a few more passes before it's logical again |
| 11:01 | <annevk> | it also has createCookie and readCookie for non-cookie code |
| 11:02 | <roc> | hsivonen: heh, we got that too |
| 11:02 | <roc> | annevk, OK, I'm going to stop trying to make it work then :-) |
| 11:02 | <annevk> | sorry, the code is logical, it's just not logically named |
| 11:04 | <hsivonen> | umm. how do sites that embed the YouTube swf player ensure that the swf doesn't get at private information on the embedding page? |
| 11:04 | <annevk> | hsivonen, yeah, blargh |
| 11:04 | <annevk> | content protection is teh evil |
| 11:11 | <zcorpan_> | hsivonen: they trust youtube? |
| 11:12 | <annevk> | most of the other issues they mention will be addressed in due course though |
| 11:13 | <corey__> | is this the proper channel for html5 discussions? |
| 11:14 | <zcorpan_> | yes |
| 11:14 | roc | hacks on fullscreen to make that one go away |
| 11:15 | <hsivonen> | zcorpan_: as far as I can tell, the embedding model is already "they trust YouTube", yes |
| 11:15 | <zcorpan_> | roc: api? for video only or anything? |
| 11:15 | <annevk> | roc, someone hacking on a spec too? |
| 11:15 | <roc> | yep |
| 11:15 | <roc> | I already proposed it in the whatwg list a while ago |
| 11:15 | <roc> | zcorpan_: everything |
| 11:16 | <hsivonen> | zcorpan_: so doing <script src="http://www.youtube.com/do/whatever/you/do.js"></script>; should work fine |
| 11:16 | <roc> | zcorpan_, annevk: https://wiki.mozilla.org/Gecko:FullScreenAPI#Gecko_Implementation |
| 11:16 | <roc> | erp |
| 11:16 | <roc> | ignore the implementation bit |
| 11:17 | <roc> | that's just a slight refinement of what was discussed here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-January/024872.html |
| 11:19 | <corey__> | are websockets a dependable technology? |
| 11:20 | <annevk> | corey__, what does that mean? |
| 11:20 | <annevk> | roc, looks pretty good, though it would be nice if we could avoid putting more stuff on Window |
| 11:20 | <corey__> | I'm asking if it's doing to be adopted by major browsers in the near future. seems to be only on chrome at the moment. |
| 11:20 | <roc> | yeah |
| 11:20 | <zcorpan_> | maybe fullscreen stuff should be on window.screen :) |
| 11:21 | <roc> | no it shouldn't |
| 11:21 | <roc> | you don't make the screen fullscreen |
| 11:21 | <roc> | I could go with "navigator is the new window" |
| 11:21 | <annevk> | corey__, other browsers are implementing it, yes |
| 11:21 | <roc> | corey__: it's on Firefox trunk |
| 11:21 | <roc> | so the next Firefox will have it |
| 11:22 | <corey__> | I was lead to believe Firefox 4 would have it? |
| 11:22 | <roc> | yeah |
| 11:22 | <roc> | annevk: thing is, Gecko already has a "fullscreen" attribute on Window |
| 11:22 | <roc> | er, fullScreen |
| 11:23 | <hsivonen> | roc: why is there already fullScreen on window? |
| 11:23 | <hsivonen> | roc: XUL stuff leaking to the Web? |
| 11:23 | <roc> | maybe, I don't know without doing the archaeology |
| 11:24 | <annevk> | seems to be unique to Gecko |
| 11:24 | <annevk> | well, at least Opera/Chrome don't have it |
| 11:25 | <roc> | I could add the new APIs elsewhere, and even a new 'fullScreen' attribute |
| 11:26 | <roc> | it's just that Window is the most logical place for it, apart from the global namespace pollution problem |
| 11:37 | <othermaciej> | roc: it seems odd that requestFullScreen is on Window but operates on an Element, instead of just being an Element method |
| 11:37 | <roc> | you might not have an element |
| 11:37 | <roc> | we could have two no-arg methods, one on Element and one on Window |
| 11:38 | <othermaciej> | would the one on Window do anything different than applying full-screen to the root element? |
| 11:38 | <hsivonen> | roc: what about non-arg methods on Element and Document? |
| 11:38 | <hsivonen> | roc: to avoid window pollution |
| 11:38 | <roc> | although there's the variation for disabling keys, so that's two methods on Element and two on Window |
| 11:38 | <annevk> | is it likely we would have other options than keys in the future? |
| 11:39 | <othermaciej> | adding to Window pollutes the global namespace, which is bad |
| 11:39 | <roc> | annevk: I don't know |
| 11:39 | <roc> | yes, I know |
| 11:39 | <hsivonen> | roc: has Document been considered? |
| 11:39 | <roc> | othermaciej: yes, making the root element fullscreen has side effects ... the default :full-screen style rule would kick in |
| 11:39 | <annevk> | othermaciej, root can be positioned within the initial containing block |
| 11:40 | <roc> | hsivonen: I'm considering it right now :-) |
| 11:40 | <othermaciej> | I think WebKit's enterFullscreen() and exitFullscreen() extensions on HTMLVideoElement could just be applied to all elements |
| 11:40 | <MikeSmith> | corey__: https://bugzilla.mozilla.org/show_bug.cgi?id=472529 |
| 11:41 | zcorpan_ | wonders what happens if you fullsceen an element that's display:none |
| 11:41 | <roc> | othermaciej: I think they behave differently from what I'm working on |
| 11:41 | <MikeSmith> | corey__: I think most of the code has already landed in gecko trunk |
| 11:41 | <othermaciej> | also it doesn't make sense to me for the shorter simpler name to be the one with keyboard disabled |
| 11:41 | <roc> | it's not |
| 11:41 | <othermaciej> | er |
| 11:41 | <othermaciej> | with keyboard enabled I mean |
| 11:41 | <corey__> | I'm using a recent minefield build and not seeing websockets enabled =/ |
| 11:41 | <hsivonen> | hmm. I guess the whatwg wiki isn't broken but instead my snapshot of Gecko doesn't support HTTP redirects |
| 11:41 | <othermaciej> | having keyboard enabled is a big security risk, so I am not sure why it should be allowed at all |
| 11:42 | <zcorpan_> | corey__: works for me |
| 11:42 | <roc> | WriteRoom, stuff like that |
| 11:42 | <roc> | lots of games need the keybaord |
| 11:42 | <othermaciej> | have you thought of a sufficient way to mitigate the security risk of a full-screen OS simulacrum? |
| 11:42 | <corey__> | zcorpan_, your version? |
| 11:42 | <hsivonen> | othermaciej: shouldn't full-screen first-person WebGL shooters support movement by letter keys? |
| 11:42 | <annevk> | it does make sense to reverse the logic I think |
| 11:42 | <zcorpan_> | corey__: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:2.0b2pre) Gecko/20100629 Minefield/4.0b2pre |
| 11:42 | <annevk> | requestFullScreenEnableKeyboard or some such |
| 11:42 | <roc> | hsivonen: well, one thing I'm thinking of is suppressing keypress, not keydown or keyup |
| 11:42 | <othermaciej> | Flash deals with this by (a) having an ugly text warning when you first enter full-screen and (b) only allowing a very limited set of keys in fullscreen mode |
| 11:43 | <roc> | annevk: ok |
| 11:43 | <MikeSmith> | kennyluck: http://blog.jclark.com/2010/01/xml-namespaces.html |
| 11:43 | <othermaciej> | hsivonen: that's a valid use case, but how do you allow it without creating the security risk of an OS simulacrum that steals your password? |
| 11:44 | <roc> | passive opt-in UI |
| 11:44 | <MikeSmith> | kennyluck: http://www.xml.com/pub/a/2005/04/13/namespace-uris.html is worth reading too (from 2005 and that article was not the first to point out the problems but it's a good summary) |
| 11:44 | <roc> | othermaciej: so if I understand correctly, webkitEnterFullScreen creates a new window showing just the video, right? |
| 11:44 | <zcorpan_> | speaking of FPS games, i wonder how to solve the problem of the mouse reaching the edge of the window |
| 11:45 | <kennyluck> | thanks, reading. |
| 11:45 | <othermaciej> | roc: are you asking about the implementation, or logically what it does? |
| 11:45 | <MikeSmith> | kennyluck: "XML Namespaces Don't Need URIs" |
| 11:45 | <roc> | the latter |
| 11:45 | hsivonen | notes that e.g. OS X "Application foo requires you to type your password" dialog could be faked without fullscreen |
| 11:45 | <othermaciej> | roc: there is no second <video> element |
| 11:45 | <hsivonen> | but Ubuntu's can't |
| 11:45 | <othermaciej> | roc: it displays the existing <video> element fullscreen |
| 11:45 | <othermaciej> | it happens to do this by creating another fullscreen window to render to, but that's an implementation detail |
| 11:46 | <corey__> | MikeSmith, every xml namespace has a uri |
| 11:46 | <othermaciej> | if keyboard access has to be granted special permission, and regular fullscreen doesn't, then it seems like poor form to have the simpler method name be the one that enables the keyboard |
| 11:46 | <MikeSmith> | corey__: yeah, too bad |
| 11:46 | <roc> | is there documentation for webkitEnterFullScreen? http://developer.apple.com/safari/library/documentation/appleapplications/reference/WebKitDOMRef/HTMLVideoElement_idl/Classes/HTMLVideoElement/index.html is a bit sparse |
| 11:47 | <othermaciej> | anyway, we would like to generalize enterFullscreen / exitFullscreen to all elements, and we were thinking of writing a proposal, but we may just comment on yours, since it is close to what we want |
| 11:47 | <hsivonen> | I agree that the way for requesting the keyboard should look more special than the way of going fullscreen without keyboard |
| 11:47 | <roc> | othermaciej: you already did comment on mine |
| 11:47 | <roc> | well, Simon did |
| 11:47 | <othermaciej> | my only concern would be that you seem to have features that are not obviously necessary for the common use case |
| 11:47 | <roc> | we had a thread about almost this exact proposal on the whatwg list in January |
| 11:47 | <MikeSmith> | corey__: sorry I meant yeah, that's the beauty of it |
| 11:48 | <othermaciej> | well, one comment I'd give is that I think enter / exit are fine verbs, and while I have no huge problem with changing them, request/cancel don't seem obviously better |
| 11:48 | <Philip`> | zcorpan_: If it's fullscreen, that doesn't seem much of a problem - there's no browser chrome for the user to click on so there's probably no security risk in disabling their cursor, so you just disable their cursor and send mouse events with dx/dy instead of x/y |
| 11:48 | <roc> | the thing is that in my model, fullscreen transitions are asynchronous |
| 11:48 | <othermaciej> | having methods on Window instead of on elements seems pretty clearly worse (to me) |
| 11:48 | <roc> | when you call requestFullScreen, you don't necessarily get it immediately, or at all |
| 11:48 | <MikeSmith> | corey__: or, I meant No, not actually |
| 11:49 | <roc> | yes, I agree moving the methods to Element and Document make sense |
| 11:49 | <MikeSmith> | corey__: take your pick |
| 11:49 | <othermaciej> | "might not get it at all" seems weird |
| 11:49 | <roc> | it might be denied |
| 11:49 | <corey__> | MikeSmith, you are very indecisive |
| 11:49 | <othermaciej> | so the user gets prompted whether to allow fullscreen? |
| 11:49 | <othermaciej> | or are you imagining a blacklist? |
| 11:50 | <roc> | I'm imagining a passive prompt |
| 11:50 | <roc> | like we do for popups |
| 11:50 | <othermaciej> | I would say that for the common limited-keyboard case, no prompting is required |
| 11:50 | <roc> | I at least want to *allow* the UA to use a passive prompt |
| 11:50 | <kennyluck> | MikeSmith, I read the latter one before. And I think it's about the centralized vs decentralized debate. |
| 11:50 | <annevk> | if it's like popups, openFullScreen() / closeFullScreen() ? |
| 11:50 | <othermaciej> | for the full-keyboard case, I don't think a prompt would be an adequate security measure |
| 11:50 | annevk | is just brainstorming a bit; don't pay too much attention |
| 11:51 | <roc> | it's not like popups other than that |
| 11:51 | <roc> | othermaciej: I don't think it's a good idea to design an API that's incompatible with any kind of prompting |
| 11:51 | <othermaciej> | I am dubious about implementing a version with full keyboard support (as opposed to, say, limited to space, enter, arrow keys) |
| 11:51 | <jgraham> | Is this supposed to be bound to explicit user actions? |
| 11:51 | <roc> | it can be |
| 11:51 | <annevk> | maybe full keyboard should only be for this new "installed apps" concept, if that is going to happen |
| 11:52 | <roc> | othermaciej: what about devices that don't have a keyboard? I mean, if you only have a touch screen, disabling the keyboard isn't a big security win |
| 11:52 | <othermaciej> | that makes more sense to me, if there is such a concept |
| 11:52 | <othermaciej> | yes, I was just thinking today about how to defend against OS simulacrum on touchscreen-only devices |
| 11:52 | <jgraham> | If it's not then the ability to have a prompt is essential. If it is then it still seems like a useful feature |
| 11:53 | <Philip`> | othermaciej: If FPS-style games are a use case, then you need to support at least the WASD keys |
| 11:53 | <othermaciej> | I think one of the most common use cases for this will be video that wants to go full-screen with custom controls |
| 11:53 | <roc> | I don't want to constrain the security design space here by making the API assume synchronous transitions |
| 11:53 | <othermaciej> | for that case, prompting of any form would be obnoxious |
| 11:53 | <roc> | is that so crazy? |
| 11:54 | <roc> | especially given that I want fullscreen features that work when the user explicitly commands fullscreen (F11 in Firefox), so asynchronous transitions happen anyway |
| 11:54 | <othermaciej> | I'm not saying it should assume synchronous transitions, because in any case it would be nice for the transition to animate and for the content to remain live during that |
| 11:54 | <hsivonen> | Philip`: and the WASD-equivalent Dvorak, French, etc. locations |
| 11:54 | <roc> | othermaciej: I agree about the common use case |
| 11:55 | <othermaciej> | Philip`: it might be interesting to investigate what subset of keys Flash allows |
| 11:55 | <roc> | othermaciej: is webkitEnterFullScreen documented anywhere? |
| 11:55 | <Philip`> | http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5 |
| 11:55 | <Philip`> | Not sure if that's a comprehensive list |
| 11:56 | <othermaciej> | roc: I don't really know, but I can get people to write a rough description of it (and related events) or write it myself |
| 11:57 | <othermaciej> | our HTMLVideoElement.idl documents the entry points pretty clearly, if not the details of behavior |
| 11:57 | <othermaciej> | there are also some events |
| 11:57 | <roc> | what my proposal does is just make the window fullscreen and apply a default style to the fullscreen element, if any |
| 11:57 | <othermaciej> | http://trac.webkit.org/browser/trunk/WebCore/html/HTMLVideoElement.idl |
| 11:58 | <roc> | that means that cases like fullscreening a display:none element are perfectly well defined |
| 11:58 | <annevk> | what is the default style? |
| 11:58 | <roc> | it can also integrate nicely with the fullscreen features Firefox already has |
| 11:58 | <othermaciej> | do you do anything to make the full-screened element grow to the size of the Window? |
| 11:59 | <roc> | *:full-screen { position:fixed; top:0; left:0; right:0; bottom:0; z-index:2147483647; background:black; } |
| 11:59 | <annevk> | interesting |
| 12:00 | <zcorpan_> | so by default you get black text on black background? |
| 12:00 | <othermaciej> | doing it that way is clever |
| 12:00 | <roc> | zcorpan_: only if you decide to fullscreen a DIV full of default-style text ... I don't think that's the common case |
| 12:01 | <othermaciej> | what I would imagine is that the element's bounds become the viewport, so you can't use CSS to make stuff surrounding the element appear in view through weird CSS rules |
| 12:01 | <roc> | the common case is <video>, which generally wants black |
| 12:01 | <othermaciej> | that makes it more obvious how to do a nice transition |
| 12:01 | <hsivonen> | can CSS animations provide nice transitions from an in-flow box into a position:fixed box? |
| 12:01 | <roc> | no |
| 12:01 | <annevk> | you could add color:white |
| 12:02 | <roc> | sure, but I honestly don't think it would matter :-) |
| 12:02 | <roc> | most of the transitions you might want to do require OS integration to make a window zoom out in some manner |
| 12:02 | <Philip`> | annevk: If somebody wants to fullscreen a page of text, they probably want it to stay black-on-white, so you should minimise the number of CSS properties they need to override |
| 12:03 | <zcorpan_> | i agree that full screen video should be black, but for anything else it's less clear it should be black |
| 12:03 | <roc> | with my approach you can make the style change happen immediately, snap the window to the old bounds of the element, and zoom it out to the full screen |
| 12:05 | <roc> | that transition would look good in most cases |
| 12:05 | <roc> | almost all cases, I suspect |
| 12:05 | <Philip`> | *:full-screen { position: ...; } video:full-screen { background: black; } ? |
| 12:05 | <roc> | yes |
| 12:05 | <roc> | that would work |
| 12:05 | <othermaciej> | if you are using this with custom controls, you are likely to be using an ancestor of the <video> |
| 12:05 | <roc> | although we don't want UA style sheets to get *too* clever |
| 12:05 | <roc> | othermaciej: yep |
| 12:06 | <annevk> | the flexibility it provides for is pretty great |
| 12:07 | <roc> | I'll make some changes, thanks for the feedback |
| 12:07 | <othermaciej> | it's not clear to me that adding a black background in fullscreen is helpful on net |
| 12:07 | <roc> | I dunno |
| 12:07 | <roc> | that's a minor detail anyway |
| 12:07 | <annevk> | yeah, me neither, but we can fiddle with those details later I suppose |
| 12:07 | <annevk> | once there's some developer feedback |
| 12:08 | <othermaciej> | I will say that our main point of feedback for enterFullscreen on <video> has been a desire for custom controls |
| 12:09 | <roc> | yes, that's essential |
| 12:09 | <othermaciej> | we have not had much direct interest in taking non-video content full-screen, but it makes sense to be fully general if you are general enough to allow custom JS-driven video controls |
| 12:10 | <othermaciej> | also one can imagine games and perhaps distraction-free apps as future use cases |
| 12:10 | <othermaciej> | or slideshows |
| 12:10 | <roc> | once you allow custom controls you have to deal with most of the security issues anyway |
| 12:11 | <othermaciej> | well, for keyboard&mouse devices at least, keyboard access is the main security risk |
| 12:12 | <othermaciej> | for touch devices, most of them have a status display at the top, so perhaps an always-on distinctive status display would be good enough |
| 12:12 | <roc> | so what would you do for touch devices? |
| 12:12 | <roc> | heh |
| 12:12 | <othermaciej> | that's the best I was able to think of |
| 12:12 | <roc> | ok |
| 12:12 | <roc> | thanks |
| 12:14 | <jgraham> | hsivonen: I am clearly still missing something. How do you cope with <table><caption><svg></caption>? |
| 12:17 | <jgraham> | It feels like it should break after the caption element is popped, but afaict it does not |
| 12:18 | <roc> | I don't really like going to requestFullScreen and requestFullScreenEnableKeys |
| 12:18 | <roc> | in the modern world it feels a bit wrong for the simple API to disable one particular input device that isn't even ubiquitous anymore |
| 12:19 | <othermaciej> | the simple API should be the one that likely does not require permission grants or pre-approval by the user |
| 12:19 | <roc> | in that case we should disable all input except the ESC key :-) |
| 12:19 | <othermaciej> | if I were designing it I'd just leave out the EnableKeys variant for v1, since Flash gets along fine without it |
| 12:20 | <othermaciej> | I think the Flash set of keys, and ESC hardcoded to always exit, is likely a pretty safe mode, at least for devices with a keyboard |
| 12:20 | <roc> | that's a big caveat |
| 12:21 | <roc> | but I'll go with this and see what people think |
| 12:22 | <roc> | oh, now I remember why I decided to have methods that take an element parameter |
| 12:23 | <roc> | it's because then I can have requestFullScreen(Element); cancelFullScreen() where cancelFullScreen takes no parameter |
| 12:23 | <roc> | so there's no confusion about what should happen if you do elem1.requestFullScreen(); elem2.cancelFullScreen(); |
| 12:23 | <roc> | I suppose I can have cancelFullScreen on the Document only |
| 12:24 | zcorpan_ | was just going to suggest that |
| 12:24 | <othermaciej> | elem1.requestFullScreen(); elem2.cancelFullScreen(); is something that is likely to arise only by mistake or in artificial test cases |
| 12:25 | <othermaciej> | or maybe I am too optimistic |
| 12:25 | <othermaciej> | anyway |
| 12:25 | <othermaciej> | I'm way overdue for some sleep, so good night folks |
| 12:26 | <roc> | heh, it must be 5:30am there |
| 12:26 | <jgraham> | hsivonen: It seems to work OK with the html5lib test cases if you break when node is no longer in the stack of open elements after step 5 |
| 12:26 | <jgraham> | hsivonen: And for the <math></html> case |
| 12:27 | <jgraham> | hsivonen: I havne't really thought about the implications of that fix though |
| 12:46 | <karlcow> | "<video> tag does not currently meet all the needs of a site like YouTube:" - http://apiblog.youtube.com/2010/06/flash-and-html5-tag.html implementer feedback |
| 13:01 | <annevk> | karlcow, you might be interested in the logs |
| 13:08 | <hsivonen> | karlcow: I believe that's "author feedback" from the usual point of view |
| 13:08 | <hsivonen> | usual on #whatwg that is |
| 13:16 | <Amadiro> | Good evening. Can someone recommend a small, handy webserver or proxy that supports websockets, both the new standard (with all the fancy encryption and hanshake stuff) as well as the older formats (as older versions of chrome implement them, for instance)? I'm currently using misultin (a tiny erlang webserver w/ websocket support) as reverse proxy, but it does not support the newer revisions of the websocket protocol. |
| 13:16 | <Amadiro> | Basically, what I want to do is connect my websocket application to my server, which uses a plain TCP connection. So the gateway has to accept the websocket, and relay the connection. |
| 13:25 | <karlcow> | hsivonen: thanks |
| 14:01 | <annevk> | why does https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI&limit=500&action=history only show changes from today? |
| 14:03 | <jgraham> | annevk: Because it was created today? |
| 14:05 | <annevk> | ooh |
| 14:05 | <annevk> | I thought this was going on for some time |
| 14:33 | <kamathln> | <a href="http://appspot.com"; href="http://appengine.google.com">; Appspot</a> |
| 14:34 | <kamathln> | <a href="svn://svn.something.com/something"; href="http://something.com/svn">; Appspot</a> |
| 14:36 | <kamathln> | <a href="htt://mylinux.dyndns.org" href="http://myblog.com/LapppyNotReachable">; Me :-)</a> |
| 14:36 | <kamathln> | what say |
| 14:36 | <kamathln> | ? |
| 14:36 | <kamathln> | alternate hrefs when the orig hrefs go bad |
| 14:38 | <annevk> | unlikely I'd say |
| 14:38 | <kamathln> | annevk: in what way |
| 14:38 | <annevk> | on a basic level it's incompatible with the HTML parser and the DOM |
| 14:39 | <annevk> | and it's not really clear there's a real need for it |
| 14:39 | <annevk> | I suggest reading through http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F |
| 14:40 | <kamathln> | I am only discussing here .. more than just for when things become unreachable, I want the browsers to be able to handle when they dont know how to handle a rotocol |
| 14:40 | <kamathln> | protocol* |
| 14:40 | <kamathln> | eg: svn protocol there |
| 14:40 | <kamathln> | <a href="htt://mylinux.dyndns.org" href="http://myblog.com/LapppyNotReachable">; Me :-)</a> |
| 14:41 | <kamathln> | whups not that |
| 14:41 | <kamathln> | <a href="svn://svn.something.com/something"; href="http://something.com/svn">; Appspot</a> |
| 14:41 | <kamathln> | that one |
| 14:41 | <Amadiro> | kamathln, so if the browser doesn't understand the svn:// protocol, it can use the alternative link? |
| 14:41 | <kamathln> | Amadiro: yes, thats the idea |
| 14:41 | <Amadiro> | (Does any browser understand the svn protocol?) |
| 14:41 | <Peter`> | wondering; there's registerProtocolHandler now, is there some kind of isProtocolKnown method? |
| 14:42 | <Amadiro> | kamathln, I kinda like the idea, I have to say |
| 14:42 | <kamathln> | Peter`: that would require Javascript right? |
| 14:42 | <Peter`> | Yes |
| 14:42 | <kamathln> | or at least some dynamic scripting |
| 14:42 | <annevk> | Peter`, there's no infrastructure around it, no |
| 14:42 | <annevk> | Peter`, not really clear that's needed |
| 14:42 | <kamathln> | with alternate linking, it need not even be dynamic |
| 14:43 | <Peter`> | annevk: I haven't thought of any use-cases or whatsoever, was mostly wondering |
| 14:45 | <Amadiro> | kamathln, I'd imagine the browser would display a message ala "This location is not available because $reason, the website suggests to visit $alternative_link instead" |
| 14:47 | <kamathln> | Amadiro: hmm, that would be possible as well. I Think I should have used the wordings "it *need not* be dynamic" |
| 14:48 | <kamathln> | non-dynamic fallback usefull when you are using resources from alternative sites |
| 14:49 | <kamathln> | from mysite1 : <img src="http://mysite2.com/kamathln/1.jpg"; alt_src="http://mysite3..com/kamathln/1.jpg">; |
| 14:52 | <kamathln> | programmers can think of this as a minimalistic try(){}catch(){} |
| 14:52 | <kamathln> | :) |
| 14:57 | <TabAtkins> | That only gives you two sources, though - even better would be to leverage CSS and the image() function (when it's supported), like <img src=foo style="content: contents, image(bar, baz, qux);">. That'll try each of the four images in turn. |
| 14:58 | <kamathln> | TabAtkins: I have been thinking about the problem.. There must be a way to specify any number of URLs |
| 14:58 | <TabAtkins> | There is. I just gave one. |
| 14:59 | <TabAtkins> | It just so happens that nobody implements that part of CSS yet. |
| 14:59 | <kamathln> | TabAtkins: that would work only for the IMG problem .. what about a href , js and css srcs ? |
| 14:59 | <TabAtkins> | Then it indeed would not work. |
| 14:59 | <kamathln> | and now, audio and video .. |
| 14:59 | <kamathln> | exactly .. |
| 15:00 | <zcorpan_> | kamathln: audio and video support multiple fallbacks already |
| 15:01 | <kamathln> | zcorpan_: Oh yeah! then it would be (sort of) shamefull to not have them for anywhere we need to specify hrefs and srcs |
| 15:01 | kamathln | starts groping for audio and video documentation to find how its implemented |
| 15:02 | <zcorpan_> | i don't see why we'd want to support fallbacks everywhere |
| 15:05 | <kamathln> | zcorpan_: did you login after I started to chat ? I already gave 3 usecases .. 1)general unaivalability of the page, 2)unaivalability of a domain providing a resource, and 3) inability of a browser to handle a special protocol (like svn, I guess) |
| 15:05 | <annevk> | they're very minor |
| 15:06 | <annevk> | and most can be checked beforehand by the page provider providing an even better user experience |
| 15:06 | <zcorpan_> | what would a browser do with an svn: link? |
| 15:06 | <annevk> | TabAtkins, not really convinced that image() proposal is a good idea to be honest |
| 15:06 | <kamathln> | launch tortoissvn? |
| 15:06 | <kamathln> | tortoisesvn? |
| 15:07 | <zcorpan_> | what's the use case for that? |
| 15:08 | <zcorpan_> | i'd rather have svn: urls written in plain text so i can copy it and paste it into my terminal or a script |
| 15:10 | <zcorpan_> | for 1), if there's reason to believe a page will become unavailable, and you have a backup page that is not unavailable, why not just link to the backup page directly? |
| 15:11 | <kamathln> | irc:// xmpp:// lastfm:// webcal:// .. etc.. |
| 15:11 | <kamathln> | svn was just one example |
| 15:11 | <zcorpan_> | what would you fall back to for those? |
| 15:11 | <kamathln> | webclients |
| 15:12 | <annevk> | (besides, only 0.0000000001% or so of all links fall in that category) |
| 15:12 | <Philip`> | zcorpan_: You may believe the backup page will become unavailable too, and more frequently than the original page, but rarely at the same time |
| 15:12 | <zcorpan_> | why not provide two links? some users might prefer the web client over the native app |
| 15:13 | kamathln | wears a second thinking cap |
| 15:14 | <zcorpan_> | Philip`: fair enough. however i haven't seen anyone work around this limitation so i'm not convinced it's a problem that needs solving |
| 15:14 | <doublec> | zcorpan_, video and audio don't have fallback in the case of the resource being unavailable - which is what I think kamathln was wanting |
| 15:15 | <zcorpan_> | doublec: sure it does |
| 15:15 | <zcorpan_> | doublec: if a video is not available, the next <source> is tried |
| 15:16 | <kamathln> | why would you provide it for video, and not img ? I still dont get. |
| 15:16 | <zcorpan_> | that's not the problem <source> was intended to solve, but it does as a side effect |
| 15:16 | <kamathln> | zcorpan_: oh okies |
| 15:16 | <Philip`> | zcorpan_: I guess the common case is that you own both the linker and linkee and run them on the same server, so if it's down then it doesn't matter what links you write; or the linker and linkee are different people, and the linker doesn't know enough about the linkee's backup/mirroring/update strategy to sensibly link to multiple URLs |
| 15:17 | <doublec> | zcorpan_, erm, I don't think it does |
| 15:17 | <doublec> | zcorpan_, if the resource fails to load then an error is raised |
| 15:18 | <TabAtkins> | annevk: image() in general, or just for this use-case? image() is just wrapping up the behavior of the "content" property in a more general fashion for images themselves. |
| 15:18 | <zcorpan_> | doublec: could you point to the relevant part of the spec that says so? |
| 15:18 | <doublec> | zcorpan_, 4.8.10.5 |
| 15:19 | <doublec> | although it appears to have changed a lot since I last read it |
| 15:19 | doublec | double checks |
| 15:19 | <zcorpan_> | "⌛ If absolute URL was not obtained successfully, then end the synchronous section, and jump down to the failed step below." |
| 15:20 | <zcorpan_> | "⌛ If the node after pointer is a source element, let candidate be that element." |
| 15:21 | <zcorpan_> | "⌛ If candidate is null, jump back to the search loop step. Otherwise, jump back to the process candidate step." |
| 15:22 | <paul_irish> | miketaylr: really? shorturl+fragment was working fine for me. it broke something? :( |
| 15:23 | <doublec> | what does "If absolute URL was not obtained successfully" mean? |
| 15:23 | <miketaylr> | paul_irish: ? |
| 15:24 | <doublec> | It's really this bit we're talking about, right? "Run the resource fetch algorithm with absolute URL. If that algorithm returns without aborting this one, then the load failed. " |
| 15:26 | <doublec> | yeah it looks like you're right zcorpan_ |
| 15:26 | <zcorpan_> | doublec: what you quoted is about <video src="">, not <source> |
| 15:27 | <doublec> | zcorpan_, no what I quoted is also in the "Otherwise, the source elements will be used; run these substeps:" section |
| 15:27 | <zcorpan_> | oh sorry |
| 15:27 | <doublec> | it seems hard to refer to parts of the spec in this area |
| 15:28 | <doublec> | lots of numbered steps and parts without subheadings |
| 15:29 | <doublec> | the resource fetch algorithm lumps 4XX errors in the same class as unsupported media which is where it confirms what you are saying I think |
| 15:29 | <doublec> | http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource |
| 15:29 | <zcorpan_> | doublec: so if it isn't aborted (because the load failed), then the next step is run which will process the next <source> |
| 15:29 | <doublec> | yep |
| 15:30 | <doublec> | lucky I didn't work on the resource selection/loading part of our implementation |
| 15:30 | <doublec> | :) |
| 15:32 | <paul_irish> | miketaylr: wrong mike. :) |
| 15:33 | <miketaylr> | so many mikes! |
| 15:33 | <zcorpan_> | firefox fails 28 out of my 35 resource selection tests |
| 15:35 | <zcorpan_> | opera fails 4, chrome fails 28 |
| 15:37 | <no_mind> | is there any attempt or demo or displaying streaming video under html5 <video> tag ? |
| 15:40 | <doublec> | zcorpan_, where are your tests? |
| 15:41 | <doublec> | zcorpan_, no doubt bug 485288 https://bugzilla.mozilla.org/show_bug.cgi?id=485288 |
| 15:42 | <zcorpan_> | doublec: not public yet :( |
| 15:45 | <annevk> | TabAtkins, image() in general I think; I don't really believe in fallback too much |
| 15:45 | <TabAtkins> | Ah, ok. |
| 15:45 | <annevk> | that it works and is used in practice, that is |
| 15:46 | <annevk> | it's definitely way too small a thing to hit 80/20 in general |
| 15:47 | <annevk> | (media might be slightly different, but even there it is mostly because the format situation is fucked up, not because fallback is needed in general) |
| 15:50 | <TabAtkins> | Hm, maybe. |
| 15:51 | <TabAtkins> | I do like the ability to fallback to a color, though. |
| 15:52 | <annevk> | how often do you see images not load? |
| 15:52 | <TabAtkins> | When I specifically know that my text won't be legible on the underlying background and am relying on an image to provide the proper color contrast, but the image is partially transparent so I can't just pair it with a background-color. |
| 15:52 | <annevk> | when we get SPDY it's even less likely you'll notice delay by images |
| 15:53 | <annevk> | it's just way too much into theoretical space |
| 15:53 | <annevk> | there's a lot of other things we could tackle instead |
| 15:53 | <TabAtkins> | Certainly. |
| 15:53 | <zcorpan_> | TabAtkins: text-shadow? :) |
| 15:54 | <TabAtkins> | zcorpan_: That only works if you *want* a shadow. |
| 15:54 | <annevk> | that images are not loading is not something that happens nowadays though |
| 15:54 | <annevk> | maybe in the nineties |
| 15:55 | <TabAtkins> | I've had broken images sit around on my sites before. ^_^ |
| 15:55 | <TabAtkins> | Though, to be fair, that stopped happening as soon as I hooked up an email script to my 404 page. |
| 15:55 | <TabAtkins> | And if an author is smart enough to know that they need fallback, they're smart enough to make their 404 page email them too. |
| 15:55 | <annevk> | cnn.com would be a fair example (especially if their developers want to tackle the issue) |
| 15:56 | <annevk> | your own site not so much |
| 15:56 | <annevk> | lets be at least a little pragmatic here :) |
| 15:56 | <TabAtkins> | I meant "a company site that I managed as the webmaster". |
| 16:01 | <annevk> | things that seem more relevant for the CSS WG to tackle: <meta name=viewport>, fullscreen API, gradients, form control styling, ... |
| 16:01 | <annevk> | also a lot more important |
| 16:02 | <hsivonen> | hmm. Nokia announces an XForms client for J2ME |
| 16:02 | <annevk> | we're now implementing this border-image thing which has become quite the complexity while form controls are still not figured out, while the table model is still undefined... |
| 16:02 | <annevk> | the priorities are way wrong imo |
| 16:03 | <hsivonen> | https://projects.forum.nokia.com/XFormsJ2ME |
| 16:05 | <annevk> | Symbian, J2ME, Maemo, ... where are they going? |
| 16:07 | <hsivonen> | annevk: looks like they are trying to keep all three for different market segments |
| 16:07 | <hsivonen> | but why XForms for any of the market segments? and why now? |
| 16:07 | <TabAtkins> | annevk: Dude, start kicking some asses then. You never talk about any of this stuff on the list or in meetings. I get easily distracted by shiny new things. |
| 16:10 | <annevk> | TabAtkins, heh, I certainly try, but it's not really working |
| 16:10 | <annevk> | TabAtkins, also, I haven't found much time to work on CSS stuff other than CSSOM |
| 16:10 | <TabAtkins> | I haven't seen much trying. ^_^ |
| 16:11 | <TabAtkins> | Yeah, granted. |
| 16:16 | <TabAtkins> | Um, does anyone implement a box-shadow-style property? |
| 16:16 | TabAtkins | doesn't think so. |
| 16:22 | <annevk> | TabAtkins, I haven't done it much recently, but it's also quite hard |
| 16:23 | <Peter`> | TabAtkins: sorry, meant box-shadow by itself |
| 16:25 | <TabAtkins> | Ah, that Peter is you? |
| 16:25 | <Peter`> | Yes |
| 16:25 | <Peter`> | I overlooked the fact that border-radius is in fact a shorthand method |
| 16:26 | <TabAtkins> | Heh, I actually forgot about that too. I only ever use the shorthand. |
| 16:26 | <TabAtkins> | (Though that's partially because of the mismatch between subproperty names between webkit and gecko.) |
| 16:26 | TabAtkins | doesn't know if that's been fixed yet. |
| 16:27 | <Peter`> | Same here, indeed :-) |
| 16:27 | <TabAtkins> | Also, remember that you can do multiple shadows right now by just specifying multiple shadows comma-separated. |
| 16:28 | <Peter`> | I didn't know that, thanks! I'll do some experimenting with it. I do remember seeing some fancy coloured shadow-examples which didn't immediately make sense -they do now-. |
| 17:05 | <TabAtkins> | Hixie: Webkit is implementing dataset right now, and uncovered a spec bug. I've emailed whatwg about it, and would appreciate a quick response. |
| 17:07 | <Philip`> | TabAtkins: Why do you think there's a problem? |
| 17:08 | <Philip`> | The part you cut out of the quote says the attribute name needs to be XML-compatible too |
| 17:08 | <Philip`> | and the processing algorithm ignores that too |
| 17:09 | <Philip`> | (i.e. empty and/or XML-incompatible names aren't allowed but will be extracted by the algorithm) |
| 17:10 | <TabAtkins> | Well, it doesn't gain us anything to process <div data-=foo>, since there isn't anything on the web that depends on it. Might as well align author and impl requirements here. |
| 17:11 | <Philip`> | Do you want to align to the XML-compatible requirement too? |
| 17:14 | <TabAtkins> | Maybe, though I'd be equally happy to drop that requirement. |
| 17:19 | <jgraham> | The empty string case is confusing |
| 17:19 | <jgraham> | So that shouldn't work, I think |
| 17:21 | <TabAtkins> | We're already verifying that the name doesn't include any capital letters, so I suspect it's not overly a burden to verify that it only contains characters in the xml-compatible range. |
| 17:21 | <TabAtkins> | (http://www.w3.org/TR/REC-xml/#NT-NameStartChar and NameChar) |
| 17:21 | <annevk> | that seems like overkill |
| 17:22 | <TabAtkins> | Possibly, yeah, so I'm not against ignoring that. |
| 17:23 | <annevk> | I don't really see why author and user agent requirements need to be aligned here |
| 17:24 | <Philip`> | TabAtkins: Do you want http://www.w3.org/TR/REC-xml/#NT-NameChar or http://www.w3.org/TR/2006/REC-xml-20060816/#NT-Name ? |
| 17:24 | <Philip`> | TabAtkins: by which I mean, I'd personally be happy to not have to care and instead to allow anything |
| 17:24 | <TabAtkins> | I linked to the one that HTML5 does, which is the extent of my caring. |
| 17:24 | <jgraham> | I think it only makes sense to allow anything, not to only process XML-compatible names |
| 17:25 | <jgraham> | Down that path lies madness |
| 17:26 | <Philip`> | Down that path lies a lot of work writing test cases and filing bugs, for no benefit to anybody |
| 17:26 | <TabAtkins> | That's cool with me. |
| 17:26 | <jgraham> | But dropping the processing of empty names seems fine |
| 17:26 | <TabAtkins> | I'm also cool with changing the author conformance to say that "data-" is valid. |
| 17:26 | <jgraham> | I see no benefit to processing them |
| 17:26 | <jgraham> | and allowing them would be weird |
| 17:28 | <Philip`> | If you don't process "data-", then should the name-setting algorithm throw an exception on dataset[""] = "foo"? |
| 17:28 | <Philip`> | to avoid losing the (I think) guaranteed roundtripping |
| 17:28 | <TabAtkins> | If we did restrict it, then yes. |
| 17:29 | <jgraham> | It could just silently ignore it |
| 17:29 | <jgraham> | That would be The ECMAScript Way (TM) |
| 17:30 | <jgraham> | (but sure, throwing INVALID_ARGUMENTS_ERROR or whatever it's called seems fine) |
| 17:30 | <Philip`> | It should silently ignore dataset["-A"] too, instead of throwing like that? |
| 17:30 | <Philip`> | (in your proposed Way (TM)) |
| 17:31 | <Philip`> | s/like that/like it does now/ |
| 17:31 | <TabAtkins> | Obviously we should match everything one way or another. ^_^ |
| 17:31 | <jgraham> | Philip`: I have no idea what it does now, and would mildly prefer throwing to ignoring |
| 17:32 | TabAtkins | sighs. |
| 17:33 | <TabAtkins> | I wish XML weren't so stupid. |
| 17:33 | <annevk> | http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0334.html -- I guess with some people "URIs" is some kind of gut reaction to problems :/ |
| 17:33 | <jgraham> | TabAtkins: Blame Tim Bray |
| 17:33 | <TabAtkins> | I will! |
| 17:33 | <jgraham> | Since everyone has the (somewhat inaccurate) idea he is the Father of XML |
| 17:34 | <TabAtkins> | Argh, he's work-at-home. So I can't bug him on campus. |
| 17:34 | <annevk> | implement XML5 in Chrome |
| 17:34 | <annevk> | it's much saner |
| 17:36 | <jgraham> | TabAtkins: You could wait 'till he next visits and follow him home |
| 17:36 | <jgraham> | and then ring on his doorbeel at three in the morning |
| 17:36 | <jgraham> | and hide out in his bins |
| 17:36 | <TabAtkins> | jgraham: Brilliant! |
| 17:37 | <TabAtkins> | annevk: XML5 being backwards compatible means that a substantial bit of craziness is still present, right? |
| 17:37 | <TabAtkins> | Like the namechar restrictions? |
| 17:38 | <annevk> | those are gone, for instance |
| 17:38 | <TabAtkins> | So it's somewhat backwards compatible? |
| 17:38 | <annevk> | there's no need for arbitrary restrictions to stay compatible with well-formed content |
| 17:38 | <TabAtkins> | kk |
| 17:39 | <TabAtkins> | Ah, so XML5 processors read XML1 content, but not the other way round. Got it. |
| 17:39 | <jgraham> | The doctype madness is still there iirc |
| 17:39 | <jgraham> | (I mean it has to be) |
| 17:39 | <annevk> | TabAtkins, depends on how you craft your XML5 content, yup |
| 17:39 | <TabAtkins> | Yeah, of course. |
| 17:39 | TabAtkins | wants something even simpler. Screw backwards compatibility. |
| 17:39 | <annevk> | jgraham, yes, it's about half the complexity of the tokenizer (or the whole parser, really) |
| 17:40 | <annevk> | TabAtkins, I don't think you can get much simpler (apart from taking out all the DOCTYPE states) while still having the expressiveness of the DOM |
| 17:41 | <TabAtkins> | I should actually look at XML5 before declaring it not-simple-enough. |
| 17:42 | <Philip`> | It seems quite common to implement XML parsers that don't support internal subsets |
| 17:43 | <Philip`> | so there'd probably be demand for a spec that isn't entirely backward-compatible in that way |
| 17:50 | <TabAtkins> | Oof, the PI and DOCTYPE stuff really is the majority of the parser. |
| 17:51 | <TabAtkins> | Ignoring those two groups, there are only 22 states. |
| 17:51 | <TabAtkins> | (And about half of *those* are just dealing with comments and CDATA.) |
| 17:52 | <TabAtkins> | Well, a third. Looks like 7 or 8 states devoted to those two. |
| 17:53 | <zcorpan_> | TabAtkins: you want XML5 but without PI, doctype, comment and CDATA? |
| 17:54 | <TabAtkins> | That'd be nice, yeah. |
| 17:54 | <TabAtkins> | Though comments are useful enough that I can accept those in there. |
| 17:55 | <jgraham> | CDATA seems pretty useful |
| 17:55 | <jgraham> | PI not so much |
| 17:55 | <jgraham> | (pity about the CDATA syntax, really) |
| 17:58 | <TabAtkins> | annevk: If I'm reading the comment states correctly, the intention is that <!-- and --> are actual comment start/end, and -- inside of them is just treated as characters? |
| 17:58 | <annevk> | yeah |
| 17:58 | <TabAtkins> | Cool. |
| 18:02 | <TabAtkins> | And all the doctype and pi states are solely to consume doctypes, not do anything with them? |
| 18:03 | <TabAtkins> | jgraham: is CDATA very useful? I really don't know - I just use <style> and <script> without worrying about the fact that they might contain things that look disturbingly like markup. |
| 18:03 | <annevk> | DOCTYPEs are processed actually |
| 18:03 | <TabAtkins> | I just assume the rest is magic. |
| 18:03 | <annevk> | to support entity references |
| 18:03 | <annevk> | and such nonsense |
| 18:03 | <annevk> | PIs are put in the DOM |
| 18:03 | <TabAtkins> | Ah, yeah, I see the PI part. |
| 18:03 | <TabAtkins> | I just skimmed the doctype states, so must have missed where they were actually parsed. |
| 18:04 | <annevk> | large parts of it are ignored |
| 18:04 | <annevk> | and are just about correctly processing them |
| 18:04 | <annevk> | but some parts are taken into consideration |
| 18:04 | <jgraham> | TabAtkins: In XML is guess it is useful |
| 18:04 | <jgraham> | I mean it is confusing if you can't do if (1<b) in your script |
| 18:04 | <TabAtkins> | jgraham: Presumably so you can do the script/style magic without having to know that the elements are magic beforehand? |
| 18:05 | <jgraham> | Yeah |
| 18:05 | <TabAtkins> | Makes sense. |
| 18:06 | <TabAtkins> | Though it should be even more explicit - it's too easy to get a nested array-reference in a numeric comparison and fake out the cdata-end state. ^_^ |
| 18:09 | <annevk> | you can just do < |
| 18:09 | <annevk> | works fine |
| 18:10 | <TabAtkins> | There is no way I'm writing |if(a[b[c]]<42) {...}| |
| 18:10 | <annevk> | you rather write <![CDATA[ crap? |
| 18:11 | <annevk> | to each his own I suppose |
| 18:11 | <annevk> | but my way requires less states :p |
| 18:11 | <TabAtkins> | If I'm handwriting? Yeah. |
| 18:11 | TabAtkins | supposes he could just avoid directly embedding non-XML languages in an xml document. |
| 18:14 | TabAtkins | would enjoy a language with only < and " as entities. |
| 18:15 | <zcorpan_> | and &? |
| 18:16 | <TabAtkins> | Right, yes. |
| 18:17 | TabAtkins | would like to find a way to avoid that, too. |
| 18:19 | zcorpan_ | finds an srt with <b><font color="#00afad">Join us on Facebook ! |
| 18:19 | zcorpan_ | Squadra Dell'Ombra</font></b> |
| 18:19 | <zcorpan_> | Hixie: ^ |
| 18:25 | <zcorpan_> | Hixie: http://www.tvsubtitles.net/subtitle-132566.html has <i>Et maintenant "Les transcroyables |
| 18:25 | <zcorpan_> | exploits de Zapp Brannigan" |
| 18:25 | <zcorpan_> | (i.e. unclosed <i> |
| 18:25 | <zcorpan_> | ) |
| 18:26 | <Hixie> | zcorpan_: i'm intentionally not going to be supporting attributes at this point |
| 18:26 | <Hixie> | zcorpan_: and will support unclosed <i>s |
| 18:28 | <zcorpan_> | Hixie: it was just the first srt i found with <b> |
| 18:28 | <Hixie> | ah |
| 18:28 | <zcorpan_> | {\pos(192,240)}On a des photos. |
| 18:28 | <zcorpan_> | http://www.tvsubtitles.net/subtitle-132551.html |
| 18:29 | <zcorpan_> | <i>{\a6}TY, |
| 18:29 | <zcorpan_> | L'ASSISTANT DU CORONER</i> |
| 18:31 | <Hixie> | wow, i wonder what UA supports that |
| 18:38 | <zcorpan_> | VLC doesn't support it |
| 18:42 | <annevk> | hmm, VLC is pretty good usually |
| 18:42 | <Hixie> | TabAtkins: you're e-mail confuses authoring criteria with implementation requirements, there's no ambiguity |
| 18:52 | <zcorpan_> | MPlayer seems to support {\pos(192,240)} |
| 18:53 | <zcorpan_> | and ignores {\a6}, or replaces it with a space or something |
| 18:56 | <Hixie> | (um, s/you're/your/) |
| 19:02 | <zcorpan_> | Hixie: all subtitles from tvsubtitles.net seem to have 9999 |
| 19:02 | <zcorpan_> | 00:00:0,500 --> 00:00:2,00 |
| 19:02 | <zcorpan_> | <font color="#ffff00" size=14>www.tvsubtitles.net</font> |
| 19:02 | <zcorpan_> | at the *end* of the file |
| 19:08 | <Hixie> | yeah, i think the parser will likely support out-of-order cues |
| 19:09 | <Hixie> | (in fact it already does) |
| 19:10 | <Hixie> | it doesn't support times with only one digit for the seconds or two digits for the thousandths, though |
| 19:10 | <Hixie> | do UAs support that? |
| 19:10 | <Hixie> | it's trivial for me to add support if necessary |
| 19:12 | <Hixie> | zcorpan_: btw so i don't miss them it'd really useful if you could note your observations of what you found in the wild on the iki |
| 19:12 | <Hixie> | wiki |
| 19:12 | <zcorpan_> | VLC supports single-digit seconds |
| 19:12 | <zcorpan_> | ok |
| 19:12 | <Hixie> | thanks for doing this btw, it's really helpful |
| 19:13 | <zcorpan_> | MPlayer too |
| 19:16 | <zcorpan_> | vlc seems to drop the thousands if they're 2 digits |
| 19:17 | <zcorpan_> | heh, vlc interprets 00:00:00,5000 as if it were 00:00:05,000 |
| 19:18 | <zcorpan_> | it's possible that it takes the two digits but it's too close to 0 for me to tell |
| 19:20 | <Hixie> | 100ms should distinguishable from 0ms, try having multiple overlapping titles |
| 19:20 | <Hixie> | oh wait doesn't vlc do automatic overlay protection? |
| 19:21 | <Hixie> | if so you can just have some that would overlap and some that would not based on how it interprets two digit times |
| 19:21 | <Hixie> | and see how it positions them |
| 19:21 | <Hixie> | bbiab, going to the office |
| 19:21 | <zcorpan_> | mplayer also interprets 00:00:00,5000 as if it were 00:00:05,000 |
| 19:25 | <zcorpan_> | ok vlc interprets 00:00:01,99 as 00:00:01,099 |
| 19:28 | <zcorpan_> | vlc seems to just overlap without changing position |
| 19:32 | <zcorpan_> | for the pay-per-minute or per-byte use case, can't the server just throttle the download as it sees fit? |
| 19:33 | <zcorpan_> | if it's on the client side it seems easy to bypass anyway |
| 20:03 | <Hixie> | zcorpan_: thanks for the notes on the wiki |
| 20:03 | <zcorpan_> | np |
| 20:25 | <Hixie> | zcorpan_: we can go several ways on the timestamp parsing thing |
| 20:25 | <Hixie> | zcorpan_: we could just support arbitrary values in each field, and then add them together without checking ranges |
| 20:26 | <Hixie> | zcorpan_: so e.g. 1:60:60,60000 would turn into 1 hour + 60 minutes + 60 seconds + 60000 thousandths, i.e. 2h2m, same as 02:02:00.000 |
| 20:27 | <Hixie> | zcorpan_: we could check ranges, but support missing zero padding, so e.g. 1:1:1,1 => 01:01:01.001 |
| 20:28 | <Hixie> | zcorpan_: or we could be strict, and not support this contentz |
| 20:28 | <Hixie> | zcorpan_: any opinions? |
| 20:34 | <Hixie> | i went with the first option |
| 20:35 | <zcorpan_> | that's what i was going to suggest (for compat with vlc and mplayer; i have no idea if there's any content that relies on this) |
| 20:37 | <TabAtkins> | Adding them all together is the best. Makes so many things simpler when you don't have to futz around with doing base-60 arithmetic yourself. |
| 20:37 | <Hixie> | well there's the content you pasted which relies on us doing either the first two and not the third |
| 20:38 | <Hixie> | TabAtkins: well they're still not valid at the moment |
| 20:38 | <Hixie> | this is just error handling behaviour |
| 20:38 | <TabAtkins> | d'oh. |
| 20:38 | <TabAtkins> | I like it when that sort of thing is expicitly allowed. |
| 20:38 | <Hixie> | we can talk about what should be valid too, but that's a discussion for another time |
| 20:38 | <Hixie> | i'm starting the format as strict as possible in terms of what's allowed, e.g. it even wants the cues in order |
| 20:38 | <Hixie> | which i imagine we'll later relax |
| 20:38 | <Hixie> | but we'll see |
| 20:39 | TabAtkins | thinks specifically of date libraries that are perfectly happy being asked to create a datetime for March -3 or whatever. |
| 20:40 | <zcorpan_> | Hixie: ah, i didn't even notice the lack of zeros in 00:00:0,500 --> 00:00:2,00 when i pasted it |
| 20:41 | <Hixie> | heh |
| 20:41 | <Hixie> | TabAtkins: there are arguments both ways on this -- in this particular case, given how easy it is to write a script that normalises the files, the benefit might not outweigh the cost |
| 20:42 | <Hixie> | (the cost is that it makes understanding what's going on kinda confusing) |
| 20:42 | <Hixie> | (e.g. you can't tell at a glance which cue is higher than which cue) |
| 20:43 | <TabAtkins> | I blame human-based timestamps. |
| 20:46 | <annevk> | http://html5.org/tools/web-apps-tracker?from=5123&to=5124 -- I hope we don't get these |
| 20:46 | <hsivonen> | annevk: congrats on the chairship |
| 20:48 | <annevk> | thanks, though the charter still needs to get approved by the AC |
| 20:48 | <Hixie> | chairship? |
| 20:49 | <annevk> | http://www.w3.org/2010/06/notification-charter.html |
| 20:50 | <Hixie> | oh, i've been ignoring that thread |
| 20:51 | <Hixie> | glad you're chairing that |
| 20:51 | <Hixie> | grats |
| 20:51 | <Hixie> | keep 'em sane! |
| 20:53 | Hixie | wonders how to structure the output of the cue text parser |
| 20:53 | <Hixie> | i could just output DOM nodes |
| 20:53 | <Hixie> | but that seems a bit heavy-weight if implementations decide to actually take me to my word |
| 20:57 | <zcorpan_> | Hixie: i think you can assume that implementors are going to cut corners |
| 21:18 | <hsivonen> | Hixie: if the cue text parser outputs DOM nodes, why not use the HTML fragment parsing algorithm? |
| 21:21 | <karlushi> | trying to imagine the concrete use cases from the report http://www.w3.org/2010/02/mbui/report.html and have difficulties to see them. I guess I should read the papers |
| 21:21 | <othermaciej> | annevk: I offer you a virtual beer of sympathy |
| 21:24 | <zcorpan_> | hsivonen: it's interleaved with karaoke timestamps and voices |
| 21:25 | <hsivonen> | zcorpan_: I didn't notice voices inside the cue text |
| 21:25 | hsivonen | looks |
| 21:25 | <zcorpan_> | hsivonen: and maybe VLC doesn't want to bundle a whole HTML parser just for websrt |
| 21:26 | <zcorpan_> | hsivonen: oh maybe not voices |
| 21:27 | <hsivonen> | zcorpan_: VLC already bundles the kitchen sink |
| 21:27 | <hsivonen> | zcorpan_: I thought we'd have learned that avoiding HTML parsing is the wrong optimization |
| 21:28 | <hsivonen> | we could mint an element for karaoke timing within cue text |
| 21:28 | <karlushi> | http://www.google.com/search?q=websrt+site%3Avideolan.org |
| 21:29 | <karlushi> | [nil] |
| 21:31 | hsivonen | still thinks karaoke stuff is a distraction as far as solving an accessibility problem goes |
| 21:32 | <karlushi> | http://trac.videolan.org/vlc/search?q=Subtitles nothing related to websrt |
| 21:33 | <zcorpan_> | hsivonen: if browsers support any elements in captions then soon enough all media players need to bundle a browser engine for compat with content |
| 21:34 | <hsivonen> | zcorpan_: maybe. one could argue that if browsers support any elements in prose, word processors need to bundle browser engines |
| 21:34 | <hsivonen> | when designing a format for the Web, needing a browser engine isn't a bug, IMO |
| 21:37 | <karlushi> | hsivonen, maybe, but it doesn't necessary help with the format having success in other environments. (thinking). If the format has no strong ties with the browser engine, I guess it doesn't matter that much. |
| 21:39 | <hsivonen> | karlushi: SRT already has success in other environments. WebSRT is leveraging that. Not the other way round. |
| 21:54 | <annevk> | both sides make sense |
| 21:55 | <annevk> | though I suspect browsers will at some point be a low-level piece of software, like unix, so having them as a requirement is probably not too bad |
| 21:56 | <TabAtkins> | "at some point"? |
| 21:57 | <annevk> | it's not quite there yet |
| 22:00 | <TabAtkins> | AryehGregor: Plus, the only pay-per-minute video I've ever seen on the web is porn. |
| 22:03 | karlushi | suddenly think that TabAtkins has spent money for nothing, there is so much free stuff out there. |
| 22:04 | <TabAtkins> | Oh, I've never paid for it. You kidding? Giving your credit card to a porn company is just *asking* for identity theft. |
| 22:04 | <TabAtkins> | I'm just saying, that's the only place I've ever seen pay-per-minute used. |
| 22:05 | <Hixie> | hsivonen: because i don't want to require that VLC embed an HTML parser when it's not necessary |
| 22:05 | karlushi | was just quoting TabAtkins ;) "I've ever seen" and being playful. |
| 22:08 | <annevk> | Hixie, the counter argument is that VLC will be eaten by the browser Godzilla in the end and that therefore complicating the browser more for the sake of VLC is not worth it long term |
| 22:10 | Philip` | kind of likes having several small independent applications, rather than one giant monolithic one |
| 22:10 | <annevk> | (and maybe/hopefully, long term HTML parsing will be like number parsing in programming languages) |
| 22:11 | karlushi | agrees with Philip` |
| 22:11 | karlushi | fears we are geeks though |
| 22:12 | <annevk> | I don't know |
| 22:12 | <annevk> | applications are on top of the platform |
| 22:12 | <annevk> | we're discussing the platform here |
| 22:15 | <annevk> | I don't mind yet another parser so much though |
| 22:16 | <annevk> | compared to layout, dynamic updates, etc., parsers are cheap |
| 22:17 | <annevk> | (though admittedly the HTML parser with script injection and all can get pretty darn complex) |
| 22:17 | <hsivonen> | Hixie: I think WebSRT is repeating the mistake that Pingback made (speccing a regexp instead of requiring real parsing) |
| 22:18 | <hsivonen> | (this time it's not a regexp but still the "can't require HTML parsing" mentality) |
| 22:18 | <hsivonen> | and we are the group that has finally solved HTML parsing so that it could now be required! |
| 22:19 | <Hixie> | hsivonen: who's speccing a regexp? |
| 22:19 | <hsivonen> | Hixie: you did in Pingback |
| 22:19 | <Hixie> | i was ten years younger then :-) |
| 22:20 | <Hixie> | i can't use the html fragment parser because it doesn't support things like timestamps, and i don't want to use the html parser because that's about 1000 times the needed complexity |
| 22:20 | <annevk> | Pingback was about finding something inside a text/html resource. That seems quite different from finding something in a text/srt resource. |
| 22:20 | <Hixie> | but i have no intention of speccing a fake parser, it'll be a real one |
| 22:20 | <hsivonen> | my point is that HTML parsing shouldn't be considered to be the bogeyman it was 10 years ago |
| 22:21 | <hsivonen> | Hixie: I'm suggesting that the HTML parser be used only for cue text |
| 22:21 | <Hixie> | sure, but the cue text has timestamps (for karaoke) |
| 22:22 | <hsivonen> | Hixie: I'm ok with a dedicated parser for the WebSRT encapsulation |
| 22:22 | <hsivonen> | Hixie: an element could be minted |
| 22:22 | <Hixie> | i don't consider the html parser a bogeyman, i consider it a massive piece of engineering and a pretty big part of my spec editing career... but it's still orders of magnitude more than we need here |
| 22:22 | <hsivonen> | Hixie: (and karaoke is on the wrong side of 80/20 anyway, IMO) |
| 22:23 | <Hixie> | i beg to differ on that last one, karaoke occurs in many (most?) anime videos, e.g. |
| 22:24 | <annevk> | most Ghibli movies I've seen so far need it |
| 22:24 | <TabAtkins> | Agreed. It's either part of most movies, or at the least part of the opening/closing credits. |
| 22:25 | <annevk> | yeah, usually at the start/ending |
| 22:25 | <Hixie> | anyway, i really don't see why we'd reuse the html parser other than just because we already have one, which is a pretty poor reason given that media players aren't going to be the same as html browsers in many cases |
| 22:25 | <annevk> | I should say Totoro again; it's pretty great |
| 22:25 | <hsivonen> | would the creators of those movies be satisfied with text tracks anyway, or would they burn their art to the pixel data? |
| 22:25 | <annevk> | s/say/see/ doh |
| 22:26 | <boazsender> | There any mention in any spec of file writing with data uri's? |
| 22:26 | <boazsender> | like if I wanted to be able to do window.location='data:dataType,' + URIEncodedData; |
| 22:26 | <hsivonen> | Hixie: I think the WHATWG would be designing a captioning format for use on the Web. if it gets picked up by standalone media players, that would be a bonus, but IMO shouldn't be a design goal |
| 22:27 | <boazsender> | ... and have that cause a file download. |
| 22:27 | <boazsender> | the above works in firefox 3.6 |
| 22:27 | <annevk> | hsivonen, you don't want to create captions twice |
| 22:28 | <hsivonen> | annevk: for the vast majority of cases, the WebSRT captions would be just like today's SRT |
| 22:28 | <hsivonen> | without fancy stuff |
| 22:28 | <annevk> | I wonder more how long the standalone player with no browser argument holds true... |
| 22:29 | <annevk> | hsivonen, presumably they would like to have conforming implementations too |
| 22:30 | <hsivonen> | annevk: we could use the "CSS is optional" pixie dust :-) |
| 22:31 | <zcorpan_> | annevk: legacy encodings is a bigger problem with existing srt |
| 22:33 | <annevk> | zcorpan_, I don't think it's about how much existing content works with WebSRT, it's more how easy WebSRT can be adopted by various vendors |
| 22:33 | <annevk> | hsivonen, as in HTML parsing is optional? |
| 22:33 | <hsivonen> | annevk: no, as in complex rendering of the data structure you get out of the HTML parser would be optional |
| 22:34 | <hsivonen> | HTML parsing is / will be off-the-shelf stuff |
| 22:34 | <annevk> | I think Hixie's point was that implementing an HTML parser was too much already |
| 22:35 | <annevk> | yeah, I think that will be true in due course too |
| 22:35 | <hsivonen> | annevk: my point is that you'll be able to use an HTML parser that's already been written |
| 22:35 | <annevk> | on the other hand, by that argument we should have used HTML for EventSource or manifest="" |
| 22:36 | <annevk> | if the part of WebSRT that is markup is significantly simpler than a full HTML parser it might be worth to have it actually be simpler |
| 22:36 | <hsivonen> | (I realize that what I say would be more credible if I was able to point to a C++ version of the V.nu/Gecko parser that didn't need Gecko stuuf around it) |
| 22:37 | <annevk> | your argument also kind of sounds like "lets use XML; it's great" |
| 22:39 | <annevk> | and we have rejected that too because of the sheer complexity |
| 22:39 | <annevk> | even though standard libraries are all over the place |
| 22:42 | <annevk> | anyway, I'm about 45min late for an appointment with a novel; nn :) |
| 22:43 | <roc> | WebSRT is renderable markup, EventSource and manifest are not |
| 22:43 | <roc> | the argument that "right now we only need a simple subset, so let's spec our own" is why SVG started encroaching on HTML and CSS |
| 22:44 | <roc> | it's troublesome because of course the requirements grow over time, and at each step the easiest thing to do for implementers, spec authors and Web authors is to add one more feature to the stand-alone subset |
| 22:45 | <roc> | however, argument by analogy is weak so that doesn't settle the issue |
| 22:46 | <AryehGregor> | I don't suppose there's any way to have, say, <input type="number"> that doesn't get validated, without adding attributes to the form itself or submit buttons? |
| 22:48 | AryehGregor | doesn't see one |
| 22:48 | <zcorpan_> | AryehGregor: i think you can override the validation of specific elements with setCustomValidity or something |
| 22:48 | <AryehGregor> | I was thinking without JS. I could always add oninvalid="return false", yeah. |
| 22:49 | <zcorpan_> | then no, afaik |
| 23:11 | <othermaciej> | for those of you who have criticized the information considered, quality of reasoning, or clarity of writing of WG decisions, I would appreciate private feedback on http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html |
| 23:12 | <othermaciej> | (I believe this includes Lachy, TabAtkins, sicking, Hixie and probably others) |
| 23:13 | <othermaciej> | I'll also be asking some non-WHATWG folks who complained in the past for their private feedback |
| 23:13 | <TabAtkins> | othermaciej: Will do. |
| 23:14 | <othermaciej> | (would rather not have a huge public debate about it but I'd like to know if people who were concerned in the past feel their concerns were addressed) |
| 23:17 | <hober> | othermaciej: as one of the zero-edit CP authors, I think that the points we raised were adequately addressed in the decision's stated rationale. |
| 23:35 | <MikeSmith> | paul_irish: about the frag ID thing, I was wrong .. seems it works in most UAs |
| 23:35 | <MikeSmith> | just wasn't working in the first one I had tried it in |
| 23:53 | <JonathanNeal> | If you were putting an image next to a word that it represents, then the alt of the image is usually the word, but in this case a screen reader will just read the word twice. |
| 23:53 | <JonathanNeal> | How should this be handled? |
| 23:55 | <JonathanNeal> | Sorry about that. Whoops. |
| 23:56 | <TabAtkins> | JonathanNeal: Description of the image, in that case. |
| 23:58 | <JonathanNeal> | But the description of the image is the content next to it. |
| 23:59 | <JonathanNeal> | Is there any way of tying these together? |
![http://mysite2.com/kamathln/1.jpg"](http://mysite2.com/kamathln/1.jpg"){kind=link}
![http://mysite3..com/kamathln/1.jpg">](http://mysite3..com/kamathln/1.jpg">){kind=link}