| 00:02 | <AryehGregor> | Hixie, I think WeBMartians meant that I made an ad hominem attack on Microsoft, by saying they care about developers more than users. |
| 00:41 | <heycam> | jamesr, hi (though busy) |
| 00:41 | <jamesr_> | heycam: so it seems the web perf WG has decided that requestanimationframe should be in their charter. the FX TF has also decided that requestanimationframe is in their scope |
| 00:42 | <jamesr_> | i'm happy to help get it standardized in some form with either group |
| 00:42 | <zewt> | what does that have to do with performance? isn't that basically a vsync feature or something? |
| 00:42 | <jamesr_> | zewt: that is somewhat mysterious to me as well |
| 00:42 | <zewt> | web perf is profiling stuff, right? |
| 00:43 | <jamesr_> | previously, yeah |
| 00:43 | <jamesr_> | they've decided to expand their charter |
| 00:43 | <zewt> | not too familiar with it, but sounds ... sort of contrived, heh |
| 00:43 | <heycam> | i think it's ok to go with web perf |
| 00:44 | heycam | must return to svg wg f2f stuff |
| 00:44 | <jamesr_> | ok |
| 00:44 | <jamesr_> | my main concern with web perf is that nobody from apple is there (i assume that you can keep roc / boris z up to date) |
| 00:45 | <roc> | I think it's OK, heycam can represent us there :-) |
| 00:46 | <jamesr_> | i guess i could harass smfr into joining the web perf WG |
| 00:50 | <AryehGregor> | Google people: are there internal Google aliases that reject all external mail or something? Some people have been sending me stuff CCd to webkit-editing⊙gc, but when I reply all, it bounces. |
| 00:50 | <jamesr_> | yes, most internal mailing lists bounce external mail |
| 00:50 | <jamesr_> | you shouldn't be CC'd on such lists in general |
| 00:51 | <jamesr_> | tell whoever is adding you to the CC list that they are doing it wrong ;) |
| 00:52 | <jamesr_> | and should probably be having the whole thread on the appropriate external list |
| 00:53 | <AryehGregor> | I told them to repost feedback to whatwg, which they by and large did, so all is well. |
| 00:53 | <AryehGregor> | Just wondering. |
| 05:42 | <Hixie> | is there a mouse capturing api in the platform? |
| 05:45 | <Hixie> | i'm doing stuff using dragging around a canvas, and i can't work out how to not have one of these bugs: |
| 05:45 | <Hixie> | 1) dragging out, releasing the mouse button, and going back in makes the ui drag things around without a button |
| 05:52 | <Hixie> | 2) dragging out and back in without releeasing the button loses the drag |
| 07:59 | <zcorpan> | Hixie: i think annevk worked around those issues in his canvas paintr |
| 07:59 | <zcorpan> | http://annevankesteren.nl/2006/08-paintr21 |
| 08:17 | <zcorpan> | lol "If your web application fails in browsers with scripting disabled, Jakob Nielsen’s dog will come to your house and shit on your carpet." http://diveintohtml5.org/history.html |
| 08:24 | <zcorpan> | boo for using sync xhr |
| 08:43 | <zcorpan> | hsivonen, MikeSmith: <meta http-equiv="Content-type" content="text/html; charset=utf-8"><meta charset="utf-8"> validates |
| 08:43 | <MikeSmith> | yeah |
| 08:44 | <MikeSmith> | validator is currently not doing any check for that at all |
| 08:44 | <zcorpan> | known? |
| 08:44 | <zcorpan> | oh? |
| 08:44 | <MikeSmith> | yeah, I filed a spec bug on this |
| 08:44 | <zcorpan> | ok |
| 08:45 | <MikeSmith> | I think the spec should just say, "A document must not have more than one character-encoding declaration." |
| 08:45 | <MikeSmith> | and leave it at that |
| 08:45 | <MikeSmith> | the current spec language doesn't even prohibit multiple <meta http-equiv="Content-type"… instances |
| 08:47 | <MikeSmith> | zcorpan: what I think we should implement is: report an error for any character-encoding declaration except the first one (in document order) |
| 08:48 | <MikeSmith> | and possibly, also report the location of the first one |
| 08:49 | <MikeSmith> | a problem with that is, this part of the code currently has no means for emitting Info-level messages |
| 08:49 | <MikeSmith> | it can only emit errors and warnings |
| 08:50 | <MikeSmith> | zcorpan: anyway, this is bug : http://www.w3.org/Bugs/Public/show_bug.cgi?id=12054 |
| 08:50 | <MikeSmith> | of course feel free to comment there if you think anything I said there is wrong, or if you have anything to add |
| 08:52 | <zcorpan> | seems fine |
| 08:53 | <MikeSmith> | ok |
| 08:53 | <karlcow> | Does it send a warning when there are conflicting? |
| 08:54 | <karlcow> | s/there/they/ |
| 08:54 | karlcow | is going to tes |
| 08:54 | <karlcow> | test |
| 08:54 | karlcow | is in typos day |
| 08:56 | <MikeSmith> | karlcow: it doesn't do anything currently |
| 08:57 | <karlcow> | the direct input does funny things |
| 09:07 | <annevk> | email is down |
| 09:07 | <annevk> | bah |
| 09:26 | <karlcow> | rha bad network here. |
| 09:27 | <karlcow> | MikeSmith: interesting thing with the meta and the validator |
| 09:27 | <karlcow> | http://validator.w3.org/check?uri=http%3A%2F%2Fwww.la-grange.net%2F2011%2F03%2F03%2Ftest%2Fvalid-charset-02&charset=%28detect+automatically%29&doctype=Inline&group=0&user-agent=W3C_Validator%2F1.2 |
| 09:27 | <karlcow> | http://validator.w3.org/check?uri=http%3A%2F%2Fwww.la-grange.net%2F2011%2F03%2F03%2Ftest%2Fvalid-charset&charset=%28detect+automatically%29&doctype=Inline&group=0&user-agent=W3C_Validator%2F1.2 |
| 09:28 | <karlcow> | the order of the meta is different but it always warn about one being wrong. |
| 09:28 | <karlcow> | which is the case |
| 09:28 | <karlcow> | but it doesn't warn there are two :) indeed |
| 09:29 | <karlcow> | I wonder if browsers pick the first one or the last one in the pile |
| 09:29 | <zcorpan> | karlcow: http://www.la-grange.net/2011/03/03/test/valid-charset has charset in http content-type |
| 09:29 | <zcorpan> | karlcow: which wins over meta |
| 09:30 | <karlcow> | ah interesting making a 3rd test |
| 09:30 | <zcorpan> | charset detection has already been researched and specified and implemented |
| 09:31 | <karlcow> | zcorpan: I would have thought that the meta/charset would win over meta/http |
| 09:33 | <karlcow> | http://validator.w3.org/check?uri=http%3A%2F%2Fwww.la-grange.net%2F2011%2F03%2F03%2Ftest%2Fvalid-charset-04&charset=%28detect+automatically%29&doctype=Inline&group=0&user-agent=W3C_Validator%2F1.2 |
| 09:33 | <karlcow> | here it says there are two |
| 09:33 | <karlcow> | "The character encoding specified in the HTTP header (utf-8) is different from the value in the <meta> element (iso-8859-1, utf-8). I will use the value from the HTTP header (utf-8) for this validation." |
| 09:33 | <karlcow> | or more exactly it sees there are two |
| 09:34 | <zcorpan> | it doesn't seem to be validator.nu that emits that message |
| 09:41 | <karlcow> | nope, probably the additional layer of W3C validator for messages |
| 09:41 | <hsivonen> | Is my reading comprehension correct that the Chairs "accepted" http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5#Details but excluded more than 50% of its proposed edits? |
| 09:41 | <hsivonen> | thus effectively formulating a middle ground that wasn't fully represented by any one CP |
| 09:42 | <hsivonen> | might have been easier to document which edits were upheld than to say which edits were excluded |
| 09:42 | <annevk> | I should have just stayed asleep |
| 09:42 | <annevk> | no email no news no nothing |
| 09:43 | <annevk> | although I guess I can concentrate more on this blog post on Web Notifications |
| 09:44 | <karlcow> | hsivonen: there's a thread in between sam and steve about it http://lists.w3.org/Archives/Public/public-html/2011Mar/thread.html#msg5 |
| 09:44 | <hsivonen> | karlcow: yeah, so it seems. thanks |
| 09:45 | <zcorpan> | annevk: you mean there's nothing that can procrastinate real work? |
| 09:46 | <karlcow> | arf http://www.opera.com/press/releases/2011/03/03/ |
| 09:46 | <karlcow> | >"I'm very concerned," says Standal. "Seventeen is very young, and I am not sure if, at that age, people are ready to use such an application. It's very fast, you know, and it has a lot of features. I think the download requirement should be at least 18." |
| 09:47 | <zcorpan> | heh |
| 09:47 | <annevk> | zcorpan, well, trying to clean up my inbox is pretty much my job |
| 09:47 | <annevk> | it contains bug reports with specs |
| 09:48 | <annevk> | but when I do that I'd like to have up to date information |
| 09:48 | hsivonen | wonders how Apple came up with 17 |
| 09:49 | <hsivonen> | aren't 15, 16, 18 and 21 more common special ages? |
| 09:49 | <karlcow> | yes very strange |
| 09:50 | <hsivonen> | I wonder how the iUniverse works for young people and people without credit cards |
| 09:50 | <jgraham> | floor((15+16+18+21)/4) maybe |
| 09:50 | <hsivonen> | I started using Apple products as a minor and without a credit card |
| 09:51 | <karlcow> | well I'm an adult (well maybe) and I do not use Mac AppStore specifically because of this credit card policy |
| 09:52 | <karlcow> | no shiny new tweetie for me |
| 09:52 | <hsivonen> | I was a hassle to get my dad pay for software using his credit cards back when vendors wanted stuff faxed to them |
| 09:52 | <hsivonen> | karlcow: don't you have a credit card or do you oppose to registering yours in order to download free stuff? |
| 09:53 | <hsivonen> | s/I /It |
| 09:53 | <karlcow> | I have credit cards but indeed you are forced to register to download free stuff |
| 09:57 | <hsivonen> | I haven't installed any apps from the Mac App Store, either |
| 09:58 | <hsivonen> | I'd probably have more credit card activity with Apple if they got rid of the territorial restrictions on movie rentals |
| 09:58 | <karlcow> | to their credits, I think the territorial stupidity is coming from the movie industry. |
| 09:59 | <hsivonen> | karlcow: that's one possibility. |
| 09:59 | <hsivonen> | karlcow: it could also be coming from the laws the Finnish copyright lobby has gotten set up to favor Finnish copyright holders |
| 09:59 | <annevk> | yeah, I think it's that each country has their own silly laws |
| 09:59 | <hsivonen> | karlcow: or it could come from Apple (incorrectly) thinking that they have to have the movies translated to the local language before they can open the store |
| 10:01 | <karlcow> | so many missed opportunities for the movie industry. Which reminds me that I should add that on my next talk on the topic. |
| 10:01 | <hsivonen> | but since Apple already sells music in Finland, they have to have had some kind of contact with the local copyright lobby anyway |
| 10:01 | <hsivonen> | the book industry is super-sad, too |
| 10:01 | <karlcow> | yep |
| 10:02 | <hsivonen> | can't get a single e-Ink-based reader device that'd make sense for both English-language and Finnish-language books |
| 10:02 | <karlcow> | many people do not understand. At least there are new publishers riding on their own fully digital. |
| 10:02 | <hsivonen> | because the broadest selection for English uses Amazon's DRM and the broadest selection for Finnish uses Adobe's DRM |
| 10:02 | <zcorpan> | "CDATA sections must start with the character sequence U+003C U+0021 U+005B U+0043 U+0044 U+0041 U+0054 U+0041 U+005B (<![CDATA[)." is easier to read than: |
| 10:02 | <zcorpan> | "CDATA sections must start with the character sequence U+003C LESS-THAN SIGN, U+0021 EXCLAMATION MARK, U+005B LEFT SQUARE BRACKET, U+0043 LATIN CAPITAL LETTER C, U+0044 LATIN CAPITAL LETTER D, U+0041 LATIN CAPITAL LETTER A, U+0054 LATIN CAPITAL LETTER T, U+0041 LATIN CAPITAL LETTER A, U+005B LEFT SQUARE BRACKET (<![CDATA[)." |
| 10:03 | <hsivonen> | zcorpan: that bit of the spec is putting specifiers ahead of implementors anyway. :-) |
| 10:03 | <hsivonen> | in other ways that is |
| 10:04 | <karlcow> | "CDATA sections must start with the character sequence "<![CDATA[" (U+003C U+0021 U+005B U+0043 U+0044 U+0041 U+0054 U+0041 U+005B)" |
| 10:04 | <karlcow> | even easier to read? |
| 10:04 | <zcorpan> | karlcow: yeah maybe |
| 10:05 | <hsivonen> | are Julian's CPs about slashes in charset all about the content-type sniffing algorithm? |
| 10:05 | <hsivonen> | or does he have CPs that affect HTML parsing? |
| 10:13 | <hsivonen> | where can I locate the different proposals that are referred to by proposal numbers in the script execution thread? |
| 10:18 | <hsivonen> | oh. there's http://www.w3.org/2002/09/wbs/40318/issue-125-objection-poll/ |
| 10:18 | <hsivonen> | I guess I need to take the time to object to it. |
| 10:18 | <hsivonen> | I'd appreciate it if I could fix bugs instead of spending time to object to these |
| 10:23 | <zcorpan> | opera has now removed uts22 charset alias matching, fwiw |
| 10:24 | <annevk> | in public builds? |
| 10:25 | <zcorpan> | i thought i saw it in a changelog of a snapshot |
| 10:25 | <zcorpan> | don't remember which and it seems i can't access the desktop team site right now |
| 10:25 | <karlcow> | annevk: http://my.opera.com/desktopteam/blog/2011/02/17/a-first-glimpse-at-barracuda |
| 10:25 | <karlcow> | "CORE-21407 remove support for UTS22 §1.4 charset alias matching" |
| 10:26 | <annevk> | nice |
| 10:27 | <karlcow> | the changelog of Barracuda is quite impressive |
| 10:30 | <hsivonen> | responded to http://www.w3.org/2002/09/wbs/40318/issue-125-objection-poll/results |
| 10:39 | <karlcow> | http://www.ecyrd.com/timeismoney/ |
| 10:39 | <karlcow> | for people who loves meetings |
| 10:40 | <zcorpan> | annevk: i would imagine showing notification in-window first and having a button on the notification to opt-in to os-level notification for the origin |
| 10:40 | <zcorpan> | annevk: and an easy way to opt-out again |
| 10:42 | <annevk> | yeah, Hixie proposed that |
| 10:42 | <annevk> | well, that was his design |
| 10:42 | <annevk> | but apparently people want to know things upfront and such |
| 10:42 | <annevk> | but maybe we should just not cater to them? |
| 10:43 | <zcorpan> | show a notification upfront? :) |
| 10:43 | <annevk> | yeah, but they didn't quite like that either |
| 10:43 | <jgraham> | Umm, that sounds quite complex |
| 10:43 | <annevk> | I forgot where this was discussed |
| 10:44 | <annevk> | and I rather have this be someone else their problem |
| 10:44 | <jgraham> | as you can't just hand off to an OS notification mechanism |
| 10:46 | <annevk> | rel=pingback unused? |
| 10:46 | <annevk> | has this person not heard of WordPress? |
| 11:17 | <zcorpan> | apparently |
| 11:20 | zcorpan | filed that bug btw |
| 11:29 | <hsivonen> | hmm. looks like @opera has "space astronauts" instead of architecture astronauts working on network operations |
| 11:31 | <zcorpan> | hmm? |
| 11:31 | <benschwarz> | adactio Whatup! |
| 11:32 | <adactio> | benschwarz: Nice work on HTML5 for developers — lovely stuff. |
| 11:32 | <benschwarz> | adactio—Thanks. I enjoyed seeing your tweet |
| 11:57 | <annevk> | hsivonen, what do you mean? |
| 11:59 | <hsivonen> | annevk: https://twitter.com/#!/opera/status/43254428245032961 |
| 11:59 | <annevk> | :) |
| 12:01 | <adactio> | I have a niggling doubt about the definition of the the figure element that I'd like to get clarified http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-figure-element |
| 12:01 | <adactio> | "The figure element http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#represents some http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#flow-content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document." |
| 12:02 | <adactio> | Is it indeed "the document" that we're talking about or is it actually "containing sectioning content"? |
| 12:02 | <adactio> | (I suspect it is indeed the whole document but I just want to make sure) |
| 12:07 | <karlcow> | I wonder if a space astronauts is like vocal singer |
| 12:07 | <annevk> | adactio, it's the whole document |
| 12:08 | <adactio> | annevk: Thanks. That's what I thought. |
| 12:08 | <annevk> | adactio, e.g. you might have a bunch of graphs in an appendix referenced from the main text |
| 12:11 | <hsivonen> | regarding http://dev.w3.org/html5/status/formal-objection-status.html : Have the FOs to adopting HTML5 as the WGs "basis for review" been withdrawn? |
| 12:12 | <annevk> | oh right |
| 12:12 | <annevk> | I need to submit a CCP today |
| 12:13 | <hsivonen> | annevk: which ISSUE? |
| 12:21 | <annevk> | 140 |
| 12:36 | <hsivonen> | I can't work out from Noah's CP if a "Conforming HTML5 Document" is allowed to have stuff in svg or math subtrees |
| 12:37 | <hsivonen> | also, I can't work out from Anne's current CCP if a "Conforming Document" is allowed to have stuff in svg or math subtrees |
| 12:37 | <hsivonen> | and with both CPs: which stuff? |
| 12:39 | <zewt> | zcorpan: seems like it may be important to be able to request permission to show os-level notifications in advance; the "ask on first use" permission model (of eg. geolocation) doesn't really apply, since by the time you need to show a notification, it's too late |
| 12:41 | <hsivonen> | does anyone remember what's a good summary of the aria:foo vs. aria-foo episode? |
| 12:41 | <zcorpan> | zewt: yeah |
| 12:41 | <hsivonen> | use case: explaining why smil:foo is bad for the exact same reasons as aria:foo |
| 12:43 | <zewt> | is anything actually using the web permissions spec yet? |
| 12:44 | <annevk> | hsivonen, there's probably some emails on www-tag explaining that |
| 12:46 | <zcorpan> | http://lists.w3.org/Archives/Public/www-tag/2008Apr/0244.html ? |
| 12:48 | <hsivonen> | zcorpan: that one explains that IBM threw its weight behind aria-foo but it doesn't explain the technical problem fully |
| 12:48 | <hsivonen> | looking at my own emails to www-tag, I don't see a nice summary among my own emails, either |
| 12:48 | <annevk> | http://lists.w3.org/Archives/Public/www-tag/2008Apr/0235.html |
| 12:48 | <annevk> | is mine, not very good though |
| 12:48 | <annevk> | but highlights some of the technical issues |
| 12:49 | <hsivonen> | annevk: thanks. that's the best one so far |
| 12:50 | <zewt> | heh the quote in that mail |
| 12:50 | <zewt> | doesn't it basically say "if we spend some cost, we can change the cost/benefit ratio" |
| 13:28 | <jgraham> | so why doesn't http://software.hixie.ch/utilities/js/live-dom-viewer/saved/858 work in webkit? |
| 13:31 | <zewt> | works in chrome |
| 13:34 | <zcorpan> | there's something weird with chrome: if i just load a saved livedomviewer, it doesn't run scripts until i edit the script contents in the input |
| 13:35 | <zcorpan> | security feature? |
| 13:37 | <zewt> | what version? seems normal in 9 |
| 13:38 | <zewt> | oh, it displays but I don't know if the onload is working |
| 13:38 | <zcorpan> | dev 11.0.686.1 |
| 13:38 | <zewt> | ah yeah contentDocument is undefined |
| 13:40 | <zewt> | looks like the data: URL isn't considered same-origin to the page itself |
| 13:41 | <zewt> | Unsafe JavaScript attempt to access frame with URL data:text/html,iframe with data: uri from frame with URL http://software.hixie.ch/utilities/js/live-dom-viewer/?... Domains, protocols and ports must match. |
| 13:41 | <bga_> | yeah |
| 13:42 | <bga_> | in ff all ok |
| 13:42 | <bga_> | http: !== data: formally |
| 13:43 | <bga_> | zewt document.write is workaround |
| 13:44 | <zewt> | oddly doesn't work in FF3 (iframe is undefined); works in 4 |
| 13:46 | <bga_> | btw this behavior is usefull for sandboxing |
| 13:46 | <zewt> | not if it's not consistent, though |
| 13:47 | <zewt> | doesn't help sandboxing if it's not sandboxed in FF4 |
| 13:47 | <bga_> | partial solution for webkit |
| 13:47 | <zewt> | i assume chrome is strict about it for some XSS-related reason or something like that |
| 13:49 | <bga_> | htmlfile for IE but i havent discovered it deeply |
| 13:50 | <jgraham> | Right, I am kind of hoping that that is special magic for data: uris |
| 13:50 | <jgraham> | Like Opera and Firefox have |
| 13:50 | <jgraham> | Because making data: cross-origin is annoying |
| 13:51 | <jgraham> | and document.write doesn't work for my case |
| 14:50 | <annevk> | answered 126, left 125 alone (would have had the same arguments as hsivonen) |
| 14:55 | <annevk> | Hixie, PDF version link of the spec is broken? |
| 15:10 | <webr3> | hsivonen, around? |
| 15:11 | <hsivonen> | webr3: yes |
| 15:12 | <webr3> | cool, re HTML+RDFa1.1 - would you be happier if there was /no/ mention at all of xmlns in that doc (html host lang for rdfa core) |
| 15:12 | <webr3> | or, mentioned only for processors for backwards compat with xhtml+rdfa1.0 with a text/html mime type |
| 15:13 | <hsivonen> | webr3: I'd be happier if neither RDFa in HTML nor RDFa in XHTML relied on xmlns:foo |
| 15:14 | <hsivonen> | and compat with existing content was achieved by hardwiring property names |
| 15:15 | <webr3> | we can't do that though sadly, there are too many to hard wire |
| 15:16 | <webr3> | we're stuck int hat we've done everything to get rid of it, but have several million docs out there with it to handle for bc |
| 15:16 | <webr3> | ack, moving topic in meeting - will pick up at a later date |
| 15:16 | <hsivonen> | webr3: don't those several million all use a handful of vocabs? Facebook, Google, Yahoo!, CC, DC? |
| 15:18 | <webr3> | we're moving to hard wire them (well for processors) - but doesn't handle all of them, will only handle some |
| 15:18 | <webr3> | and we have in charter the bc thing, so can't avoid |
| 15:19 | <webr3> | we've made it so authors can forget movign forward, and we don't mention xmlns, /but/ the extra rules needed to handle bc for text/html are goign to make it prominent in that doc |
| 15:19 | <hsivonen> | webr3: charters are set by the people in the WG, so it's not really credible to point to charter as something that forces you |
| 15:19 | <webr3> | so 50+ mentions in HTML+RDFa1.1 - and 1 in rdfa core :| |
| 15:22 | <Philip`> | Instead of mentioning "xmlns" explicitly, you could discourage people from using it by calling it "U+0078 LATIN SMALL LETTER X, U+006D LATIN SMALL LETTER M, U+006C LATIN SMALL LETTER L, U+006E LATIN SMALL LETTER N, U+0073 LATIN SMALL LETTER S" |
| 15:31 | <karlcow> | Philip`: not sure, that would encourage perverts |
| 15:34 | <annevk> | zewt, hey, you around |
| 15:34 | <annevk> | zewt, http://www.w3.org/2006/webapi/track/issues/35 |
| 15:34 | <annevk> | it seems form submission works by dispatching a synthetic submit event |
| 15:36 | <annevk> | it also seems that Ian described "form submission" in the wrong way |
| 15:36 | <annevk> | it is triggered by the submit event, but it is not defined that way |
| 15:38 | annevk | filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 |
| 15:42 | <zewt> | looks like we came to the same conclusions he did |
| 15:43 | <annevk> | yeah, that's positive |
| 15:43 | <annevk> | I'm leaning towards only initEvent() resetting stuff |
| 15:43 | <annevk> | and then making the first argument of initEvent optional too |
| 15:44 | <zewt> | i think like you suggested, resetting in init*Event makes most sense--prevents the canceled flag from being set and then the cancel flag from being unset (inconsistent state), and avoids both the problems of early-reset and late-reset during dispatch |
| 15:44 | <annevk> | yup |
| 15:44 | <annevk> | and when we get fancy-objects I guess we should let initEvent take an object |
| 15:44 | <annevk> | instead of a series of arguments |
| 15:45 | <annevk> | so you can easily set all the properties |
| 15:45 | <annevk> | and then "deprecate" init*Event and not allow them on new event objects |
| 15:45 | <zewt> | the "set the properties manually" idea would be nice but that seems way too different from the current model where most event properties are readonly |
| 15:45 | <karlcow> | http://robert.accettura.com/blog/2011/03/03/wanted-native-js-encryption/ |
| 15:46 | <annevk> | zewt, oh yeah, we could do that too still... |
| 15:46 | <annevk> | zewt, they'd still be readonly while dispatching |
| 15:46 | <zewt> | i think it'd need to ... yeah what you said |
| 15:46 | <zewt> | so you can't change them for trusted events, in particular |
| 15:46 | <annevk> | hmm, gotta run again; should be online at tenish though |
| 15:46 | <zewt> | it's tenish now, here :P |
| 15:46 | <zewt> | (okay, elevenish) |
| 15:46 | <annevk> | timezones |
| 15:48 | <zewt> | should also be defined that non-trusted submit events perform their default action, if it isn't (iirc only click is explicitly mentioned) |
| 16:13 | <Moo-_-_> | karlcow: wanted native gzip too :) |
| 16:56 | <MikeSmith> | if anybody is interested in doing some book writing on HTML5, please let me know. I have an acquisitions editor I can put you in contact with |
| 16:56 | <MikeSmith> | ping me here or DM me or e-mail me at mike⊙wo |
| 17:11 | <jgraham> | MikeSmith: I totally read DM as "Dungeon Master" |
| 17:11 | <MikeSmith> | heh |
| 17:48 | <TabAtkins> | Can <object>'s contents be thought of as accessibility fallback? I'd dismissed that offhand earlier, but anne is bringing it up as a solution. |
| 17:49 | bfrohs | thought that's what it was already |
| 17:49 | <TabAtkins> | I thought it was functionality fallback, but I may be drawing a distinction that doesn't exist. |
| 17:49 | <jgraham> | I thought this distinction was important for <video>? |
| 17:49 | <jgraham> | Or was that some other distinction? |
| 17:50 | jgraham | tired |
| 17:50 | <TabAtkins> | I don't... I don't know. I'm confused now. |
| 17:50 | <jgraham> | In any case I disagree with anne I think |
| 17:50 | <jgraham> | <object> is worse than <canvas> |
| 17:50 | <zewt> | using canvas as an IMG seems questionable, since they're very different things (eg. progressive image rendering is very IMG-specific) |
| 17:51 | <jgraham> | zewt: It seems natural to load an image with a declarative src and then draw on it |
| 17:51 | <TabAtkins> | jgraham: In that case you can just use <img> and then draw it in, though. |
| 17:51 | <zewt> | what would it mean? would it be immutable while it's loading (like an img), and only allow drawing ops after the load finishes? |
| 17:52 | <TabAtkins> | I'd be inclined to say "don't touch it until you see a load, because it'll explode". |
| 17:52 | <zewt> | (eg. act as if you stuck an img on top of the canvas, then blitted the img onto the canvas and deleted the image at onload) |
| 17:52 | <TabAtkins> | Alternately, interacting with it between the time you set @src and when 'load' fires will abort the load. |
| 17:53 | <TabAtkins> | That counts as "explode" |
| 17:53 | <TabAtkins> | jgraham: If you could comment on why <object> is bad news, that would be nice. I can't formulate a forceful enough objection. |
| 17:55 | <jgraham> | TabAtkins: For all the normal reasons that <object> is bad |
| 17:55 | <TabAtkins> | I'm insufficiently familiar with why <object> is bad, I've just picked up the religion. |
| 17:55 | <zewt> | a lot of stuff currently specced for img would seem to need to be defined for canvas (onload, "fully decodable" and so on)--i'd hope there's a simpler way |
| 17:55 | <jgraham> | It tries to do many things and none of them well |
| 17:56 | <jgraham> | So you don't get media-specific apis and so on |
| 17:56 | <TabAtkins> | zewt: All those are already defined, so it would just be a matter of "do [this]". |
| 17:57 | <zewt> | they're defined for images, canvas isn't complicated by them |
| 17:57 | <TabAtkins> | jgraham: Is there much in the way of media-specific APIs for <img>? I grok why we did <video>/<audio> instead of extending <object>. |
| 17:57 | <TabAtkins> | zewt: I don't understand what distinction you're trying to draw. All the algorithms are well-defined and can be trivially reused. |
| 17:58 | <TabAtkins> | None of them depend on the name of the element. |
| 17:59 | <zewt> | (let me reread your mail and think for a bit) |
| 17:59 | <zewt> | (not that I'll necessarily have any ideas) |
| 17:59 | <zewt> | hmm... seems like the obvious, but impossible, solution would be to put the alternate data in the children of img; impossible since img can't have children, of course |
| 18:00 | <TabAtkins> | Yes, indeed. That's why I'm turning to the idea of using the *other* image element. |
| 18:00 | <zewt> | my first impression would be to define another tag which is completely synonymous with <img> but has children, eg. <cimg>, sharing 99% of the spec and (preferably) the same object type--existing only to syntactically allow it to have descendents |
| 18:01 | <TabAtkins> | Didn't somebody suggest doing that for <image>? |
| 18:01 | <zewt> | don't know |
| 18:01 | <bfrohs> | TabAtkins: I think so |
| 18:14 | <zewt> | another possibility would be something like <img src=foo.jpg id=foo><fallback for=foo>...</fallback>, which degrades a bit more nicely |
| 18:15 | <TabAtkins> | That seems weirder. |
| 18:15 | <zewt> | (modelling label, of course) |
| 18:19 | <TabAtkins> | presumably <fallback> wouldn't render if the element that it was for rendered correctly? |
| 18:19 | <zewt> | yeah, something like that--something like "hide this element by default, and show it if the target is in an error state" |
| 18:25 | <zewt> | degradation would require users to have a script to hide <fallback> when it's not supported, but image loading would be unchanged |
| 18:45 | <AryehGregor> | Hixie, could you get me sample execCommand() usage in the wild? |
| 18:45 | <AryehGregor> | Probably I should also research some major WYSIWYG implementations. |
| 19:04 | <TabAtkins> | Is there any strong technical objection against the 'beforeprint' event that IE fires? |
| 19:06 | <TabAtkins> | Google docs changes the rendering of the document for printing if you hit Ctrl+P or select Print from the in-app menu, but it can't tell if you hit Print from the browser's menu. |
| 19:06 | <Ms2ger> | media=print |
| 19:07 | <TabAtkins> | That doesn't let you run arbitrary JS. |
| 19:07 | <TabAtkins> | Unless you can have matchMedia? |
| 19:07 | <TabAtkins> | Hmm... |
| 19:07 | <Ms2ger> | I was about to mention that |
| 19:12 | <TabAtkins> | I suggested that we implement matchMedia instead. |
| 19:13 | <TabAtkins> | Now, back to writing an email summarizing a subtle technical issue with floats. |
| 19:14 | Ms2ger | screams at CSS2.1 |
| 19:14 | <TabAtkins> | I'd just scream at floats. They're defined SO BADLY. |
| 19:14 | <TabAtkins> | I don't think anyone recognized at the time how complex they are. |
| 19:15 | <Ms2ger> | They're not hard, if you use them as intended |
| 19:15 | <TabAtkins> | No, they're always hard. You just don't realize it. |
| 19:15 | <Ms2ger> | Just don't start making float-based layouts |
| 19:16 | <Ms2ger> | (Hi most of the web) |
| 19:16 | <TabAtkins> | Perfectly natural-looking use-cases turn out to be subtly odd |
| 19:16 | <Ms2ger> | dropcaps! |
| 19:16 | <TabAtkins> | For example, I'm almost certain the spec doesn't cover the case exercised by: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/859 |
| 19:17 | <TabAtkins> | (Remove the / in front of the float to swap behavior.) |
| 19:17 | <TabAtkins> | The float drops to the second line, some of the content following it jumps to the previous line, while some of the content that was previous on the same line as it drops to the line below it. |
| 19:17 | <TabAtkins> | s/previous/previously/ |
| 19:17 | <zewt> | sounds like some kind of dance routine |
| 19:17 | <Ms2ger> | I'm pretty certain I can find undefined things in most of CSS2.1 |
| 19:18 | <Ms2ger> | Even if they're not explicitly called out |
| 19:18 | <TabAtkins> | Oh, indeed. |
| 19:18 | <Ms2ger> | Hence the scream |
| 20:00 | AryehGregor | realizes his definition of node position is totally, totally broken |
| 20:26 | <emersonvinicius> | Hello everybody |
| 20:27 | <emersonvinicius> | sorry my english, but what the diference of spec whatwg instead w3c? |
| 20:28 | <Ms2ger> | http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? explains it better than I ever could |
| 20:28 | <emersonvinicius> | Ms2ger: thx |
| 20:40 | <AryehGregor> | Note to all who may be concerned: doing simultaneous alert()s in fifty or so iframes at once makes Firefox unhappy. |
| 20:41 | <TabAtkins> | Anyone mind if I rewrite every sentence involving floats to a new, subtly backward-incompatible version that actually makes sense? |
| 20:41 | <AryehGregor> | In what spec? |
| 20:41 | <Ms2ger> | CSS |
| 20:41 | <Ms2ger> | And no |
| 20:41 | <zewt> | at least in ff4 i'll get to stop killing the entire browser every time I inadvertently cause an alert loop. heh |
| 20:42 | <AryehGregor> | Yeah, but that doesn't help if you create fifty alerts from fifty separate iframes. Apparently the "don't show more" box doesn't work then. |
| 20:43 | <TabAtkins> | Sounds like a good rick-rolling situation. |
| 20:43 | <zewt> | i havn't squinted hard enough at the "pause" part of the spec, but I'd expect an alert (of any modal type) to pause scripts on the whole window, so you can only have one alert at a time even across iframes |
| 20:43 | <zewt> | (i know that's the case with a single document; just not sure off-hand how that translates to iframes) |
| 20:45 | <zewt> | oh, since it pauses the event loop, and iframes are in the same event loop, it should pause all iframes in the window together |
| 20:51 | <zewt> | same bug as async scripts running during prompts, i guess |
| 21:03 | <Hixie> | AryehGregor: i dunno how much use it'll be but http://aupeople.com.au/1/aupeople2/read.php?tid=60099 is a random sample of some pages with "execCommand(" and "<script" |
| 21:03 | <Hixie> | AryehGregor: i don't have an easy way to get pages that have JS files that use execCommand(, which unfortunately is going to be the majority of your interesting cases |
| 21:03 | <Hixie> | AryehGregor: but e.g. i'm sure google docs uses it |
| 21:03 | <AryehGregor> | Ah, okay. |
| 21:03 | <AryehGregor> | Yeah, it's probably best to look at specific high-profile examples. |
| 21:04 | <Hixie> | yeah |
| 21:04 | <bfrohs> | Google Docs, AFAIK, does not use execCommand anymore. They ran into a ton of inconsistencies with browsers and I believe they ended up creating their own API for it in javascript (create characters off-screen, take measurements, and move them into place). |
| 21:05 | <Hixie> | hm, possible |
| 21:05 | <TabAtkins> | Docs does EVERYTHING manually. |
| 21:05 | <Hixie> | it'll still be interesting though as it'll be able to show the use cases that are important |
| 21:06 | <bfrohs> | Yeah, that's very true. |
| 21:06 | <bfrohs> | Gmail/hotmail/etc WYSIWYG editors as well. |
| 21:21 | <annevk> | I really like my idea of removing all initXXXEvent in favor of initEvent(object) |
| 21:21 | <annevk> | well, removing all future initXXXEvent |
| 21:26 | <jamesr__> | i never understood why i have to create a mouse event and then init it before it's really a mouse event |
| 21:26 | <zewt> | it just sets the properties, since most of them are read-only |
| 21:27 | <annevk> | so yeah, the alternative would be removing all future initXXXEvent in favor of read-write attributes before and after dispatch |
| 21:28 | <annevk> | but the initEvent() design is probably slightly better, as that also cleanly resets the "trusted flag" and maybe also the "propagation flag" and such if we decided to do that |
| 21:28 | <zewt> | could deal with the getters problem by just defining it as operating on a copy, eg. var copy = {}; for(key in obj) { copy[key] = obj[key]; } but sorting the keys, which would be a simple way of defining how getters are called |
| 21:28 | <zewt> | (doesn't work for structured clone, but works here since it's not recursive) |
| 21:28 | <annevk> | heycam can sort that out :) |
| 21:29 | <annevk> | though it should allow arbitrary nested objects, e.g. for CustomEvent |
| 21:29 | <zewt> | having properties be writable when not in dispatch would be nicer, but sort of unusual behavior |
| 21:31 | <zewt> | wonder if there's any precedent for that--properties which are only conditionally read-only |
| 21:31 | <heycam> | i like the idea of just writable properties on Events |
| 21:31 | <heycam> | instead of 50-argument init methods |
| 21:31 | <zewt> | either idea gets rid of the horrible init methods |
| 21:31 | <othermaciej> | giant init methods suck |
| 21:32 | <othermaciej> | otoh it is weird if you can alter the property of an event being dispatched by the UA |
| 21:32 | <othermaciej> | I guess altering any properties would have to clear the "trusted" flag |
| 21:32 | <zewt> | othermaciej: needs to be read-only when the dispatch flag is set |
| 21:33 | <zewt> | that'd be weird--setting a property would effectively imply preventDefault for most eventts, which would be confusing |
| 21:34 | <annevk> | heycam, the idea was to have initEvent(object) instead |
| 21:34 | <heycam> | annevk, ah. that works too. |
| 21:34 | <annevk> | writable attributes does not solve the problem of resetting some flags not exposed by attributes |
| 21:34 | <heycam> | right, ok |
| 21:34 | <heycam> | i wasn't really considering them |
| 21:35 | <annevk> | e.g. the moment you modify you want the "trusted flag" to be false |
| 21:35 | <heycam> | aha |
| 21:35 | <heycam> | well that you could do |
| 21:35 | <annevk> | defining that for each attribute would be kind of weird |
| 21:35 | <heycam> | but you couldn't then reset it to true |
| 21:35 | <heycam> | actually you never want that do you |
| 21:35 | <zewt> | i think the current readonly flags in events should stay readonly (at least during dispatch), not silently clear trusted |
| 21:35 | <annevk> | heycam, yeah, it would never be set back to true |
| 21:36 | <heycam> | you could just make the writable attributes also set the internal trusted flags, it's easy enough |
| 21:36 | heycam | doesn't mind either way |
| 21:36 | <annevk> | yeah, it could be done, it just seems less intuitive |
| 21:37 | <annevk> | zewt, this is for when a trusted event is dispatched and then modified after dispatch |
| 21:37 | <zewt> | annevk: right, I'm saying you shouldn't be able to modify it during dispatch at all |
| 21:38 | <annevk> | I don't think I suggested otherwise |
| 21:38 | <zewt> | <annevk> e.g. the moment you modify you want the "trusted flag" to be false <- modify when? if you modify outside of dispatch it doesn't matter (trusted will be reset on dispatch anyway) |
| 21:40 | <zewt> | i guess i'm assuming the trusted flag is only important during dispatch |
| 21:42 | <annevk> | i want isTrusted to always be correct |
| 21:42 | <annevk> | anyway, if not for the "trusted flag" it would also go for the "canceled flag" |
| 21:42 | <zewt> | then initEvent(object) seems simpler--one entry point to clear the flag |
| 21:42 | <annevk> | and for that using initEvent() is also better, as otherwise you'd have to set an attribute to reset it... |
| 21:44 | <Hixie> | yeah this CDATA paragraph is ridiculous |
| 21:44 | <Hixie> | what was i thinking |
| 21:45 | <zewt> | i was assuming there'd still be initEvent() for the base event flags, and only the additional properties would be writable |
| 21:46 | <zewt> | eg. e.initEvent("click", true, true); e.offsetX = 10; ... |
| 21:47 | <Hixie> | (please don't let events be modified during dispatch) |
| 21:47 | Ms2ger | tries to get Hixie back in the business of writing evil test cases |
| 21:54 | <annevk> | Hixie, some browsers allow it, but yeah, that's the plan |
| 21:54 | <annevk> | zewt, eww |
| 21:57 | <zewt> | might be sort of handy that you can initEvent(object) with the same object multiple times (though of course you could implement that manually, copying properties from a saved object) |
| 22:05 | <Hixie> | nessy: so, it's likely going to be time to actually do this multitrack thing soon. it seems there's been lots of discussion about it in public-html; is there a summary anywhere of the current thinking? |
| 22:05 | <nessy> | Hi Hixie |
| 22:05 | <Hixie> | in particular, list of use cases, implementation constraints, anything like that? |
| 22:06 | <nessy> | try this: http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API |
| 22:06 | <nessy> | I'll be working with Eric Carlson on a change proposal |
| 22:07 | <nessy> | the proposal that Microsoft did is too limited and only restricted to audio tracks |
| 22:08 | <Hixie> | that page is great |
| 22:09 | <Hixie> | i considered reopening http://www.w3.org/Bugs/Public/show_bug.cgi?id=9452 but i wasn't sure whether that was appropriate or not |
| 22:09 | <Hixie> | since we had agreed to assign it to the tf |
| 22:09 | <Hixie> | and then it got closed and escalated while assigned to the tf |
| 22:10 | <AryehGregor> | Okay, deleteContents() is probably finished. Hurrah. |
| 22:12 | <annevk> | zewt, I don't see why we'd disallow that |
| 22:13 | <zewt> | just mean, one (minor) handy side-effect of the init(object) approach |
| 22:14 | <annevk> | ah k |
| 22:16 | <annevk> | once we have that initEvent(object) stuff we could also make that automatic |
| 22:16 | <annevk> | document.createEvent(interface, initObject) |
| 22:16 | <nessy> | yeah, I think they worked through all the remaining open bugs and just escalated them to issues - though some slipped the cracks - I don't claim to understand |
| 22:16 | <annevk> | or maybe new MouseEvent(initObject) at some point... dunno though |
| 22:17 | <annevk> | would be a lot of additional things to test for somewhat minor benefit |
| 22:17 | <annevk> | pretty easy to make these things way more complicated than they need to be because the problems are so simple |
| 22:17 | <nessy> | Hixie: you can either try and work through it now and understand all the options etc, or you can wait until the call for change proposals closes and you have some more thought-through proposals to work through |
| 22:17 | <zewt> | doesn't seem very important to have a lot of redundant shortcuts for event init |
| 22:18 | <nessy> | the main problem we still haven't looked at is how to actually render all this stuff - and how to address it through CSS |
| 22:18 | <nessy> | that's not in that wiki page |
| 22:19 | <Hixie> | nessy: well i don't want to step on any toes here. If the bug was filed today, I would probably just address it, but then there wouldn't be pending CPs and whatnot. |
| 22:19 | <zewt> | personally I'm not crazy about the separate fireEvent() suggestion for the same reason--doesn't seem worth the redundancy |
| 22:20 | <nessy> | Hixie: no toes to step on - people are looking for a solution and are prepared to put in effort to help get there - but we all want the best possible outcome |
| 22:20 | <Hixie> | nessy: I don't want to have people feel like they have worked on something and then have me just come along and change it, but i also don't want y'all to work on something if you'd rather i just went ahead and did my thing like i usually do :-) |
| 22:20 | <nessy> | it's not a simple task though, so if you have a good solution, it would be awesome to push it! |
| 22:20 | <annevk> | zewt, right, I think initEvent(object) is probably the simplest approach to something sane here |
| 22:20 | <Ms2ger> | AryehGregor, how about you write tests for intersectsNode, then I can get it into Gecko ;) |
| 22:21 | <zewt> | yeah |
| 22:21 | <nessy> | how about you do your thing like you usually do, but put it forward as a change proposal rather than pushing it into the spec? |
| 22:21 | <Hixie> | nessy: well i don't have anything right now, but i'm sure i would come up with something (maybe good, maybe not) if i were to go through that wiki page |
| 22:21 | <annevk> | zewt, the advantages are no crazy initXXXEvent methods, it makes event interfaces extensible, and does not change much about the current model |
| 22:21 | <AryehGregor> | Ms2ger, maybe I'll take a look tomorrow. |
| 22:21 | <Hixie> | nessy: i hate writing CPs |
| 22:21 | <Hixie> | nessy: they take 10 times longer than writing spec text |
| 22:21 | <nessy> | just add another option to the wiki page then? |
| 22:21 | <nessy> | or engage in the discussion to state which option(s) you prefer? |
| 22:22 | <nessy> | it's good to come up to speed so we can shoot down the bad change proposals/options early IMHO |
| 22:22 | Ms2ger | will be out for the weekend |
| 22:23 | <Hixie> | nessy: what is the direction you and eric are likely to go in for your CP? |
| 22:23 | <nessy> | that's the hard question |
| 22:23 | <nessy> | Eric submitted option 8 and I think that's the main one he is after |
| 22:24 | <nessy> | but we have already found that option 1 will be necessary in addition so we can make adaptive HTTP streaming work |
| 22:24 | <Hixie> | looking at this i think a variation on 6 is probably what i'd mainly propose |
| 22:24 | <nessy> | and we have found cases where a total replacement of the resource is necessary, which could be done with option 6 or 7 |
| 22:24 | <Hixie> | anything that messes with <track> is flat-out wrong since video/audio tracks have nothing to do with text tracks, and as something near the top says, anything that messes with <source> is a nightmare in waiting |
| 22:25 | <Hixie> | however, 6 wouldn't really help with multiple tracks in one file |
| 22:25 | <nessy> | Philip is mostly for 6 or 7 |
| 22:26 | <Hixie> | i imagine if i were to try to spec this it'd be a hybrid of all of the above plus some more out-of-the-box thinking |
| 22:26 | <Hixie> | e.g. with a controller object as the master and all the <Video>s as slaves |
| 22:26 | <nessy> | well, the discussion about 8 is on the list - you should engage with Eric/David about that, because they are very keen on 8 |
| 22:26 | <nessy> | haha, that's option 4 - and very smil-like |
| 22:27 | <Hixie> | it's similar to 4 |
| 22:27 | <Hixie> | and similar to 6 |
| 22:27 | <Hixie> | probably wouldn't be an element though |
| 22:28 | <nessy> | interesting! |
| 22:28 | <nessy> | throw it in the wiki and add it as a proposal to the email thread? |
| 22:28 | <Hixie> | i'd have to actually spend the time to consider this, i'm just making stuff up here |
| 22:29 | <nessy> | that's how we all started... |
| 22:30 | <Hixie> | whenever i make proposals without thinking them through, they end up implemented and with legacy content before i have a chance to correct them |
| 22:30 | <Hixie> | so... |
| 22:30 | <nessy> | I actually quite like option 8 right now - it leaves the main a/v in place as the controlling entity and the others are clearly dependent |
| 22:30 | <nessy> | but I'm, keen to see yours! |
| 22:31 | <Hixie> | option 8 is a non-starter imho, it messes with <track> in a nonsensical way |
| 22:31 | <Hixie> | it's unclear to me whether external sign-language tracks need to be supported without JS, and what the use case is for inline embedded videos being controlled from JS. |
| 22:31 | <Hixie> | are there same pages anywhere? |
| 22:31 | <Hixie> | sample |
| 22:31 | <Hixie> | not same |
| 22:32 | <nessy> | let me see - I stared a collection some time ago... |
| 22:33 | <nessy> | how's this http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_Rendering |
| 22:33 | <nessy> | incomplete, but has some ideas.. |
| 22:35 | <Hixie> | we really should look at how people do this today in more detail before we write proposals |
| 22:36 | <nessy> | mostly sign language is picture-in-picture or two videos next to each other |
| 22:37 | <nessy> | there's not that much more options anyway |
| 22:37 | <nessy> | I'm thinking about rendering that we could render all the active video tracks in a video into the single viewport and have two rendering modes: a tiling approach and a picture-in-picture approach |
| 22:38 | <Hixie> | yeah but do people use two videos? one video with two tracks? |
| 22:38 | <Hixie> | do they let people control both videos separately? |
| 22:38 | <nessy> | on modern TV all the time |
| 22:38 | <Hixie> | etc |
| 22:38 | <nessy> | actually, there's a third display mode, usually used on tV |
| 22:39 | <nessy> | the main video is large and a couple of other views are tiled down the side |
| 22:39 | <nessy> | when you select one of the smaller tiles, it becomes the big one and swaps position with the big one |
| 22:40 | <Hixie> | TVs aren't really good as a precedent here since they have very different interaction modalities and constraints |
| 22:40 | <TabAtkins> | I've never seen that used on tv. |
| 22:40 | <nessy> | my uncle had a TV like that in Germany 5 years ago - I was quite impressed - probably had a set-top box |
| 22:41 | <nessy> | typically used for sports games to allow people to have different perspectives |
| 22:41 | <zewt> | annevk: re "Conflicts" - it sort of makes sense to require initEvent to be called, since in practice you probably don't want to take the default and dispatch an event with e.type == "" |
| 22:41 | <nessy> | there is only a single timeline though and only one control |
| 22:42 | <zewt> | (which I assume is why DOM Events disallows e.type == ""; that seems to be what's checked when requiring initEvent to be called, so it doesn't need a separate "has been initialized" flag) |
| 22:43 | <annevk> | zewt, what does DOM3Events say should happen when it is not called? what does it say should happen .type returns? or .eventPhase returns? lots of things are undefined |
| 22:43 | <annevk> | zewt, I'm not sure putting arbitrary restrictions in place really makes sense |
| 22:43 | <zewt> | not sure; I'm looking more at browser behavior than the spec |
| 22:44 | <annevk> | I'm also not sure why he thinks event.type can be null in D3E |
| 22:44 | <zewt> | it can't be, in either browser I tried |
| 22:44 | <annevk> | e.g. D3E says it has to be at least one character and has multiple places say it cannot be an "invalid string" |
| 22:44 | <zewt> | (by spec I don't know) |
| 22:45 | <zewt> | (predictably, I havn't read the entire DOM Events spec :) |
| 22:45 | <annevk> | would be cool to know what Jacob thought about how the spec was written |
| 22:46 | <annevk> | but I should sleep some and then read everything again and then reply |
| 22:48 | <TabAtkins> | annevk: Re using <object> for inline fallback on images, <object> is horrible for video and audio, but I'm not sure if there are any APIs we have to worry about for static images that <object> won't expose. |
| 22:50 | <zewt> | seems generally unpleasant to have people start putting images in object tags... |
| 22:50 | <annevk> | using <object> if you want rich fallback is the argument we have been using for years |
| 22:50 | <annevk> | if it is invalid I would appreciate to learn why, as it works fine for me |
| 22:51 | <nessy> | TabAtkins: I've found something similar: http://gigaom.com/video/att-lets-cubs-fans-choose-their-own-camera-angle/ - though this brings in different channels rather than tracks of the same video |
| 22:52 | <annevk> | whatwg.org uses <object> for an image by the way |
| 22:54 | <TabAtkins> | nessy: Ah, that's a cool use-case. |
| 22:54 | <Hixie> | <object> works pretty well for images |
| 22:56 | <jamesr__> | i still think the 'fallback-ish' behavior for <canvas> is bizarre |
| 22:58 | <zewt> | FWIW, object doesn't have naturalHeight/naturalWidth, or complete (doesn't define the "available" state like <img> does) ... not necessarily critical for the cases where you want rich fallback (eg. you're probably not blitting it into a canvas) |
| 22:59 | <Hixie> | jamesr__: how would you do it instead? |
| 23:00 | <zewt> | to sum up my earlier two suggestions, 1: have another tag, eg. <cimg>, which is identical to <img> but allows descendants, and put fallback data there; 2: have a <fallback for=id> tag (like <label>) which is only shown if the given id is not |
| 23:00 | <fantasai> | hsivonen: just wanted to note that we just ran into a HTML parsing issue with </! starting a tag sequence |
| 23:00 | <fantasai> | hsivonen: in case that's an interesting test case for you |
| 23:01 | <annevk> | zewt, neither is backwards compatible |
| 23:01 | <zewt> | the <canvas> suggestion isn't, either |
| 23:02 | <annevk> | well I'm not really considering that one either |
| 23:02 | <zewt> | <fallback> can be made to degrade sensibly with a little scripting help, at least |
| 23:02 | <annevk> | with scripting everything can be made to work... |
| 23:02 | <zewt> | (eg. check if HTMLFallbackElement exists; if not, add fallback { display: none; }) |
| 23:02 | <nessy> | TabAtkins: here's one with multiple angles on a single game http://www.sportsgeekery.com/2010/10/28/watch-tnts-nba-games-online-with-overtime-extra/ |
| 23:03 | <annevk> | lets all look at what we can safely remove instead :) |
| 23:18 | <nessy> | Hixie: I added a few more examples to http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_Rendering |
| 23:20 | <Hixie> | i don't understand the third one down |
| 23:20 | <Hixie> | there only seems to be one video on the page mentioned by the blog post cited on that page, the sign-language one |
| 23:22 | <Hixie> | the firstone seems to just be single standable videos with one track |
| 23:23 | <Hixie> | the second one seems to just be two unrelated videos rendered on top of each other |
| 23:24 | <Hixie> | for the fourth one, the olympics thing, it's unclear to me what the requirements are. It looks like just four unsynchronised live streams, which we can do today. If they're to be synchronised, I guess that's more like proposals 4/6 -- separate <video>s that are slaved to each other. |
| 23:25 | <Hixie> | unclear to me what the 5th is showing. |
| 23:25 | <Hixie> | or the 6th |
| 23:26 | <Hixie> | the 7th is burnt-in. |
| 23:26 | <Hixie> | presumably pretty much whatever we do will support the equivalent rendering with two tracks, so long as you can sync it somehow. |
| 23:28 | <Hixie> | 8th is the same as the 2nd, it seems |
| 23:29 | <Hixie> | dunno what the 9th is. |
| 23:29 | <Hixie> | 10th is like the 7th. |
| 23:29 | <Hixie> | 11th too |
| 23:31 | <Hixie> | 12th is like the 4th, assuming they're synchronised. four streams slaved to each other with one set of controls. |
| 23:34 | <Hixie> | 13th is weird, looks like multiple unsynchronised video streams in some incarnations, and more like the slaved case in others. |
| 23:35 | <Hixie> | the last one is more like the olymics thing again |
| 23:35 | <Hixie> | so in conclusion it looks like we have the following kinds of use cases here: |
| 23:35 | <Hixie> | 1. unsynchronised video streams next to each other (possible today with <video>) |
| 23:36 | <Hixie> | 2. an additional track, either in a separate file or in the same file, providing a sign-language overlay, which must be synchronised to the primary track, and presumably which can be turned off and on. |
| 23:36 | <Hixie> | 3. multiple independent tracks that need to be played along the same timeline |
| 23:37 | <zewt> | (do deaf people seriously use sign-language overlays? heh) |
| 23:38 | <Hixie> | zewt: some do. There's a lot of variety in the deaf community from what I understand, but certainly there are those that use sign-language overlays. |
| 23:39 | <zewt> | that's ... odd, heh |
| 23:39 | <Hixie> | why? |
| 23:39 | <zewt> | hard to think of why you'd want sign language instead of text, since I don't imagine you can watch someone signing while actually watching whatever video contains whatever's being signed |
| 23:39 | <AryehGregor> | I'd imagine you could watch sign-language as well as printed text. |
| 23:40 | <zewt> | text you can read in half a second and go back to the video |
| 23:40 | <Hixie> | sign-language is much denser than text, and you end up seeing it out of the corner of your eye |
| 23:40 | <AryehGregor> | Is the sign language we're talking about here animated, or some type of sequence of symbols? |
| 23:40 | <Hixie> | neither, it's live action of someone signing |
| 23:40 | <AryehGregor> | Interesting. |
| 23:40 | <AryehGregor> | Sign language is developed instinctively, like speech and unlike writing. |
| 23:41 | <AryehGregor> | Sign languages reliably arise spontaneously whenever you have a critical mass of deaf children and no local sign language for them to learn. |
| 23:41 | <zewt> | possibly a similar use case would be animated karaoke tracks of the sort fansubs like to use, which are way outside of webvtt's scope |
| 23:41 | <AryehGregor> | Whereas writing was an invention that was invented independently maybe like three times. |
| 23:41 | <AryehGregor> | And alphabetic writing was invented once. |
| 23:41 | <AryehGregor> | In all of human history. |
| 23:41 | <zewt> | having a separate baked video track overlaid on top of the video would be a lot nicer (in theory) then baking them right into the video |
| 23:42 | <AryehGregor> | So maybe sign language is much easier to follow than writing, if you grew up speaking it. |
| 23:42 | <zewt> | well, signing is more like speech than writing, and speech arises on its own too |
| 23:42 | <aho> | i imagine it's more like having someone talking to you |
| 23:42 | <aho> | instead of reading something |
| 23:43 | <zewt> | (one practical problem with karaoke overlays is video codecs generally don't support alpha, or if they do underneith it's never implemented) |
| 23:44 | <aho> | what's the new name of websrt again? :> |
| 23:44 | <zewt> | webvtt |
| 23:44 | <zewt> | (don't know why it was renamed, much harder to remember, heh) |
| 23:44 | <nessy> | there's also signwriting, btw - I think in the long run that has the most potential to become a machine-readable sign language |
| 23:45 | <nessy> | Hixie: I will make some notes on the examples |
| 23:45 | <aho> | i really wonder why they didn't go with something more straightforward... like... y'know... websubtitles :> |
| 23:46 | <nessy> | in general, your conclusion seems sound though |
| 23:46 | <aho> | or websubs lol |
| 23:46 | <nessy> | I took those examples also so we can see how multiple tracks can be displayed |
| 23:47 | <Hixie> | aho: webvtt has the advantage of an obvious filename extension (.vtt) that isn't used by anyone already (unlike .sub) |
| 23:47 | <nessy> | vtt = video text track - not that bad IMHO |
| 23:47 | <Hixie> | also "sub"-anything is someone misleading since we do more than subtitles |
| 23:47 | <aho> | still kinda hard to remember |
| 23:48 | <zewt> | we'll get used to it :) |
| 23:48 | <zewt> | better than .ASS |
| 23:48 | <aho> | oh yea, i remember that discussions from many moons ago... going with some "ASS" based name would have been fun :> |
| 23:48 | <nessy> | lol |
| 23:49 | <zewt> | don't know any particular discussion, just another common sub format :P |
| 23:50 | <aho> | basically, someone made a subset of aas and the idea was to call it small ass or something like that :> |
| 23:50 | <aho> | WebAss would have been fine, too |
| 23:51 | <aho> | haha |
| 23:51 | aho | is easily amused |
| 23:53 | <nessy> | (Hixie: re third one down - I was simply looking for an example where the sign language video would sit in same size as main video next to it, but I couldn't find an image better than this - maybe I am mistaken to have thought I'd seen that before) |
| 23:54 | <zewt> | sign language track - as a separate element or as an overlay? |
| 23:55 | <Hixie> | nessy: that's why it's important to have actual examples. :-) |
| 23:55 | <zewt> | (of course you can do both by overlaying two <video> elements, but that's sort of the wrong layer in general I'd think) |
| 23:55 | <Hixie> | zewt: that's what we're discussing |
| 23:55 | <aho> | zewt, would allow resizing and moving it around though |
| 23:55 | <nessy> | Hixie: you're right - I might remove that one and add your comments on all, so we keep track (not just in the bug tracker ;-) |
| 23:55 | <Hixie> | nessy: one use case that hasn't been talked about here that i'm interested in is playing two videos back synchronised but at different offsets |
| 23:55 | <aho> | full screen would be f-ed though :l |
| 23:56 | <Hixie> | nessy: something like the "double youtube" thing but where you can pick the synchronisation point |
| 23:56 | <zewt> | yeah, if you're on a TV you probably want something like PIP for that, not side-by-side |
| 23:56 | <nessy> | aho: when we attach full screen to page elements, it's possible still |
| 23:56 | <aho> | ah yea... there was that thing |
| 23:57 | <nessy> | Hixie: is that use case not just a toy? I'm worried we end up with SMIL ... |
| 23:57 | <aho> | does any browser support it today? |
| 23:57 | <zewt> | programmatic fullscreen doesn't exist yet at all afaik |
| 23:57 | <aho> | so far i've only seen very slow video fsm |
| 23:57 | <aho> | (full screen mode, not flying spaghetti monster) |
| 23:57 | <nessy> | aho, not yet - but it's being discussed |
| 23:58 | <zewt> | well yeah all (afaik) video implementations right now are really bad at fullscreening, presumably that'll get fixed |
| 23:58 | <Hixie> | nessy: toys are good too :-) |
| 23:58 | <Hixie> | nessy: it's the kind of thing that would be good to support if it can be done in a way that doesn't add complexity |
| 23:58 | <zewt> | Hixie: being able to adjust the offset is also useful to, for example, quickly adjust off-sync audio or captions |
| 23:59 | <Hixie> | yeah, that too |
| 23:59 | <nessy> | yeah, but then we get those that say that we need to be able to arbitrarily align any video track and audio tracks and have choices between subparts of them etc |
| 23:59 | <nessy> | that really is SMIL and I would prefer to keep such stuff to JavaScript |
| 23:59 | <Hixie> | nessy: e.g. if we have a controller + slaves model, you can imagine a model where the controller doesn't have a timeline, it just controls the velocity (and pauses everything whenever any of them stall), which would let you do all of the above with very minimal additional complexity |