| 00:01 | <tantek> | Thanks for the discussion and write-up Hixie. Looking forward to seeing the full(-)screen/dialog stuff make progress. |
| 00:01 | <tantek> | Now, as far as fullscreen vs full-screen vs fullScreen ... |
| 00:01 | <hober> | indeed |
| 00:09 | <TabAtkins> | I think we should use :fullScreen in CSS, and full-screen in JS. |
| 00:35 | jwalden | tries to add to this discussion, thinks it is self-beclowning enough that he need not contribute |
| 02:01 | <Hixie> | TabAtkins: wow you almost had me responding to you there |
| 02:01 | <Hixie> | TabAtkins: i need to update my troll detector's firmware! |
| 03:13 | <MikeSmith> | heh, "self-beclowning" |
| 07:17 | <charlvn> | #tkkrlab |
| 07:18 | <charlvn> | ah sorry, ignore that, didn't type the command correctly |
| 07:40 | <smaug____> | annevk: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-mutationobserver-observe context object should be target, not options |
| 07:42 | <Ms2ger> | smaug____, why's that? |
| 07:43 | <smaug____> | Ms2ger: well, I don't understand how context object can be options |
| 07:43 | <annevk> | smaug____: we can just say it is for those substeps |
| 07:43 | <annevk> | childList etc. are all discussed in the context of options then |
| 07:43 | <Ms2ger> | It's just with(options) { foo(childList); } |
| 07:43 | <Ms2ger> | Instead of foo(options.childList) |
| 07:44 | <annevk> | it's only for 1 |
| 07:44 | <smaug____> | ah |
| 07:44 | <smaug____> | so it is not for 2. |
| 07:45 | <smaug____> | strangely worded |
| 07:45 | <annevk> | how would you word it? |
| 07:45 | <smaug____> | well, don't talk about context object A in 1. and context object B in 2. |
| 07:47 | <annevk> | that would make them much more verbose |
| 07:48 | <annevk> | but if this is hard to comprehend, maybe we should do that |
| 07:49 | <annevk> | if someone else tells me the same thing I'll take a look |
| 07:49 | <smaug____> | both I and sicking were reading that last week |
| 07:49 | <smaug____> | and thought that there was something odd |
| 07:49 | <smaug____> | also, that doesn't say what happens to transient observers |
| 07:50 | <smaug____> | er, perhaps it does |
| 07:50 | <smaug____> | but I think it is not right |
| 07:51 | <smaug____> | existing transient observers should be removed, I think, when calling observe() |
| 08:12 | <annevk> | fullscreen proposal looks good |
| 08:12 | <annevk> | apart from the missing bits or the bits I'm missing :p |
| 08:45 | <annevk> | smaug____: when do you plan on removing the prefix? |
| 08:45 | <annevk> | smaug____: having a prefix does not help if we want people to move away from the old API |
| 08:56 | <annevk> | http://rumotan.com/guan/modules/tinyd3/ multiple doctypes, incompatible encoding declarations, multiple root elements, good times |
| 08:57 | <annevk> | but apart from how to deal with big5, I think most of what a user agent has to do there is actually now defined |
| 08:57 | <annevk> | we've come a long way since 2004 :) |
| 08:58 | <jgraham> | (this comment was redacted for cynicism) |
| 09:28 | <smaug____> | annevk: I agree |
| 09:28 | <smaug____> | annevk: need to stabilize the API still a bit, IMO |
| 09:29 | <smaug____> | add that takeMutation() or something similar |
| 09:29 | <smaug____> | takeMutations() |
| 09:30 | <smaug____> | annevk: what is Opera's plan |
| 09:30 | smaug____ | should ask also MS |
| 09:30 | <smaug____> | When will MS release IE10? |
| 09:34 | <annevk> | we're fine with the API, just need to free up resources |
| 09:36 | <annevk> | takeMutations() sounds pretty terrible btw |
| 09:38 | <smaug____> | foo.take*() is used often in gecko, when the idea is to return some existing object(s) and drop the reference to those in foo |
| 09:38 | <smaug____> | but perhaps it is a bit ugly name :) |
| 09:41 | <annevk> | what is the problem with having disconnect() return them? |
| 09:41 | <annevk> | the pending records |
| 09:41 | <annevk> | that seems quite clean to me |
| 09:41 | <smaug____> | that sounds very odd |
| 09:41 | <smaug____> | that disconnect() returns anything |
| 09:42 | <annevk> | yeah maybe |
| 09:42 | <smaug____> | also, I think we want a method to take the current records, but still keep observing |
| 09:42 | <smaug____> | fetch() doesn't sound too bad |
| 09:42 | <annevk> | fetch is network related usually |
| 09:42 | <annevk> | getPendingRecords() ? |
| 09:43 | <smaug____> | get* doesn't indicate that the records are dropped in the observer |
| 09:46 | <annevk> | maybe it should be takeMutationRecords |
| 09:47 | <annevk> | all sounds bad :( |
| 09:47 | <smaug____> | takeRecords() ? |
| 09:47 | <smaug____> | yeah |
| 09:47 | <annevk> | takeRecords() is better than takeMutations at least |
| 09:48 | <annevk> | and it returns sequence<MutationRecord> I guess |
| 09:48 | <annevk> | hmm |
| 09:50 | <annevk> | whoa https://www.gov.uk/designprinciples is pretty awesome |
| 09:54 | <Ms2ger> | Much as I hate github, https://github.com/alphagov is nice |
| 10:24 | <jgraham> | Yeah, the people doing UK Government we/open access data stuff seem to be pretty awesome |
| 10:24 | <jgraham> | Oh, that was the same words annevk used. |
| 10:24 | <jgraham> | I didn't mean to do that |
| 10:27 | <jgraham> | s/we/web/ |
| 10:27 | <jgraham> | So many errors. I should really have said anything at all. |
| 10:28 | <annevk> | was that intentional? :) |
| 10:28 | <jgraham> | Fuck |
| 10:28 | <jgraham> | No |
| 10:28 | <annevk> | if it's any consolation, I'm amused |
| 10:29 | <jgraham> | Good, good |
| 10:30 | <annevk> | zcorpan: btw re fullscreen, I decided that layout would be someone else's problem |
| 10:30 | <annevk> | zcorpan: it seems I might have to define it after all though, but at least Hixie worked out how (mostly) |
| 10:30 | <annevk> | (re some comment on outline from late last night) |
| 10:34 | <jgraham> | (having siad all of that one of the examples on that page about what not to do actually poited to a really interesting page about keeping bees. Which in turn allowed me to find an even more interesting page about keeping pigs and the regulations associated with that) |
| 10:34 | <Ms2ger> | siad? |
| 10:35 | <jgraham> | I know |
| 10:35 | <Philip`> | poited? |
| 10:35 | <annevk> | jgraham is the gsnedders of typing today :p |
| 10:35 | <jgraham> | gsnedders is full of fail? |
| 10:35 | <Ms2ger> | Oh, brun |
| 10:36 | <annevk> | jgraham: didn't mean it quite like that |
| 10:36 | <annevk> | oh well |
| 10:36 | <jgraham> | :) |
| 10:36 | <annevk> | so some of these big5 pages like the trailing "..." thing too |
| 10:36 | <annevk> | but they are probably implemented using PHP or so with no respect for lead and trail bytes |
| 10:36 | <zcorpan> | what thing? |
| 10:37 | <annevk> | "This sentence is too l..." |
| 10:37 | <annevk> | so you get a lead byte followed by a . |
| 10:38 | <annevk> | which is invalid of course and is invalid in each browser, and ends up as noise in my data |
| 10:38 | <zcorpan> | ah |
| 10:38 | <Philip`> | "... an AML2 ‘report of a pig movement’ form ..." - surely that'd generate a huge amount of paperwork unless you tie your pig down to stop it wandering around |
| 10:39 | <jgraham> | I imagine it work like geolocation events. |
| 10:40 | <zcorpan> | i've seen stuff like "See my résum&acut..." too |
| 10:40 | <zcorpan> | er, wrong entity, but you get the idea |
| 10:41 | <Ms2ger> | You mean "See my <a href=resume>r�sum&eacut..." |
| 10:45 | <annevk> | 20 2E 2E 2E is also used it seems |
| 10:45 | <annevk> | preceded by a lead byte |
| 10:46 | <annevk> | alright, so the errors are indeed actual errors in the pages |
| 10:50 | <annevk> | oops, made an error |
| 10:51 | <annevk> | in the A3 byte checking |
| 10:52 | <annevk> | instead of about 50 pages using quite a few A3 reserved stuff, there's only two pages with one sequence each |
| 10:53 | <annevk> | #win |
| 10:58 | <annevk> | in one page it's inside a <meta>; in the other page it doesn't render correctly anywhere... |
| 11:02 | <annevk> | I wish the component when filing bugs would always be HTML5 spec |
| 11:05 | <zcorpan> | why did that bug get the wrong component? |
| 11:05 | <zcorpan> | Hixie: ^ ( https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 ) |
| 11:05 | <zcorpan> | it got 'other hixie drafts' |
| 11:06 | <annevk> | all bugs filed via WHATWG get that |
| 11:07 | <annevk> | it changed quite some time ago |
| 11:07 | <zcorpan> | oh? |
| 11:08 | <zcorpan> | oh well |
| 11:08 | <annevk> | I've been meaning to ask Hixie to change that around, because more than one silly revert requests was because of that |
| 11:08 | <annevk> | not that anyone cares about that anymore these days, so maybe that's why I forgot |
| 11:30 | <annevk> | http://speakerdeck.com/u/jaffathecake/p/application-cache-douchebag mwaha |
| 11:31 | <annevk> | appcache is hard |
| 11:34 | <annevk> | some of this content is rather weird |
| 11:34 | <annevk> | "Strongly agree!!! Letting unlimited pregnant ladies come to HK to deliver is ridiculous! We shall follow what Western countries are doing: stop letting pregnant ladies in. " |
| 11:34 | <annevk> | some kind of forum thread |
| 11:37 | <annevk> | <center><table border=0><tr><td valign=top><html><head><meta http-equiv=Content-Type content="text/html; charset=big5"> |
| 11:37 | <annevk> | :) |
| 11:41 | <Ms2ger> | Well said, HolyEagle |
| 11:42 | <Ms2ger> | I love how that site uses document.layers |
| 11:47 | <annevk> | HolyEagle knows where it's at |
| 11:48 | <jarek> | why SVG filters renders so slow on user agents? Is it a technical limitation or does the implementation is just unoptimised? |
| 11:48 | <Ms2ger> | Because nobody uses them, I guess |
| 11:48 | <jarek> | even simple gausian blur can lock Chrome when you zoom it in |
| 11:49 | <jarek> | oops, sorry for typos |
| 11:49 | jgraham | guesses the right answer is "yes" |
| 11:49 | <jgraham> | and probably would still be if you s/or/and/ |
| 11:49 | <jgraham> | That is, I wouldn't be surprised if there are SVG filters that are intrinsically slow |
| 11:50 | <jgraham> | But I would be surprised if they are optimised in implementations |
| 11:50 | <jgraham> | +well |
| 11:51 | <jarek> | I have noticed that even professional software such as Adobe Illustrator "cheats" when rendering filters |
| 11:51 | <annevk> | found this page that has no DOCTYPE, encoded in big5, tries to nest <form> inside <tr> (one <table>, three <tr>, three nested <form>), and the kicker is that the form submits to some URL wiht a query parameter whose value contains big5 encoded characters |
| 11:52 | <jarek> | so it looks like it's impossible to render them in real time without high CPU usage |
| 11:53 | <annevk> | jarek: should probably bring that up on public-gfx⊙wo or some such |
| 11:54 | <jarek> | annevk: no, I don't want W3C to stop adding new filters :P |
| 11:55 | <jarek> | annevk: I should rather nag the vendors to implement GPU accelerated rendering |
| 12:36 | <roc> | yeah |
| 13:42 | <annevk> | Ms2ger: or did something change and are you willing to publish DOM Parsing through the HTML WW now? |
| 13:42 | <annevk> | euh, WG |
| 13:42 | <Ms2ger> | Nothing changed, why? |
| 13:43 | <annevk> | http://lists.w3.org/Archives/Public/public-html/2012Apr/0027.html |
| 13:44 | Ms2ger | shrugs |
| 13:44 | <annevk> | the HTML WG, where the chairs are robots, the editors don't care, and a few people circlejerk |
| 13:45 | <Ms2ger> | One more abandoned spec in the HTMLWG, news at 10 |
| 13:45 | <annevk> | heh |
| 13:45 | <annevk> | it's not exactly abandoned |
| 13:47 | <annevk> | make it modular, make it modular, make it modular |
| 13:48 | <annevk> | but oh god, once you do that and decentralize development, people get upset |
| 13:48 | <annevk> | decentralized extensibility please, developed centralized please |
| 13:49 | <Ms2ger> | I wonder if they're going to stick a "Copyright W3C" onto it to prevent forks |
| 13:51 | <Ms2ger> | Heh |
| 13:52 | <Ms2ger> | Web Workers still references Web DOM Core |
| 13:53 | <annevk> | I guess Julian only cares about IETF draft references |
| 13:54 | <Ms2ger> | And code points |
| 13:54 | <annevk> | not the Encoding spec though |
| 13:55 | <annevk> | maybe it needs more references |
| 13:55 | <annevk> | at some point I should reference 1) Unicode and 2) all the old silly specs that were wrong |
| 13:56 | <zcorpan> | why do you need to reference the wrong specs? |
| 13:57 | <annevk> | we do that in DOM4 too, for people who are interested in prior work |
| 13:57 | <Ms2ger> | Is position:center a thing? |
| 13:58 | <annevk> | Ms2ger: http://dev.w3.org/csswg/css3-positioning/#center-positioning |
| 13:58 | <annevk> | Ms2ger: it's been floating around on www-style for ages |
| 14:00 | <annevk> | http://webkitmemes.tumblr.com/post/20464202966/meanwhile-in-the-reviewers-lounge lol |
| 14:00 | <Ms2ger> | Yay, concesus! |
| 14:00 | <Ms2ger> | http://s3.amazonaws.com/data.tumblr.com/tumblr_m1v3rkjMvL1rrf1eeo1_1280.jpg?AWSAccessKeyId=AKIAI6WLSGT7Y3ET7ADQ&Expires=1333634508&Signature=9yoalJSJC6bZgj%2FvsRzlv47%2Bxfc%3D |
| 14:05 | <matjas> | zcorpan: https://github.com/douglascrockford/JSLint/issues/114#issuecomment-4766052 what just happened |
| 14:06 | <MikeSmith> | Ms2ger: thanks for writing up warnings for the DOM specs |
| 14:06 | <Ms2ger> | Yw |
| 14:07 | <annevk> | matjas: old news man |
| 14:07 | <matjas> | annevk: no I mean… you actually got crockford to fix something |
| 14:08 | <matjas> | well, new to me |
| 14:08 | <Velmont> | :-) |
| 14:23 | <annevk> | bdo, bdo:matches([dir=ltr i], [dir=rtl i]) |
| 14:23 | <annevk> | why does the second selector matter? |
| 14:24 | <zcorpan> | matjas: apparently it's harder to get someone to fix jshint |
| 14:25 | <Ms2ger> | annevk, specificity? |
| 14:26 | <annevk> | Ms2ger: yeah guess so |
| 14:26 | <annevk> | Ms2ger: also, http://lists.w3.org/Archives/Public/public-html/2012Feb/0479.html |
| 14:27 | <Ms2ger> | "Ms2ger @ Mozilla" <ms2ger⊙gc> |
| 14:27 | <Ms2ger> | Hah |
| 14:29 | <zcorpan> | it seems mighty weird to use the escalation process for drafts that are not owned by the html wg |
| 14:31 | <jgraham> | s/ for drafts.*// |
| 14:32 | <Ms2ger> | What he said |
| 14:32 | <annevk> | stop escalating things jgraham :p |
| 14:32 | <zcorpan> | why do i keep getting empty emails from dave.penkler⊙hc ? |
| 14:32 | <annevk> | zcorpan: me too |
| 14:32 | <annevk> | if I ever meet him, I might tell him to fix his email client |
| 14:32 | zcorpan | marks as spam |
| 14:33 | <annevk> | lots of www-tag ends up in my spam folder these days |
| 14:33 | <Ms2ger> | You've got a good spam filter, then |
| 14:33 | <zcorpan> | why are you subscribed to www-tag? |
| 14:34 | <annevk> | I found it interesting at one point and then never reevaluated my position |
| 14:50 | <annevk> | so out of the 609 pages that did not fail to download, 22 have "problematic" sequences |
| 14:50 | <annevk> | and 2 of those are big5-hkscs so they're probably not problematic |
| 14:52 | <jgraham> | So 3% of pages? That is quite a lot |
| 14:56 | <annevk> | yes |
| 14:56 | <annevk> | but only 0.01% of the characters or so |
| 14:56 | <annevk> | the problem is however there's no interoperability |
| 14:57 | <annevk> | see http://lists.w3.org/Archives/Public/www-archive/2012Apr/0019.html for the data |
| 14:59 | <annevk> | oh shit |
| 15:01 | <annevk> | off by one error |
| 15:01 | <annevk> | teehee |
| 15:01 | <annevk> | all the URLs are wrong |
| 15:02 | <annevk> | :( |
| 15:07 | <jgraham> | Wow, some range of emotions there |
| 15:07 | <annevk> | still sick |
| 15:08 | <annevk> | corrected data is here: http://lists.w3.org/Archives/Public/www-archive/2012Apr/0020.html |
| 15:10 | <annevk> | I think I just got misattributed http://infrequently.org/2012/04/one-for-dave-and-david/ |
| 15:12 | <jgraham> | I have no memory of anyone saying that the disconnect between host objects and native objects is pure awesome that has to be preserved |
| 15:13 | <jgraham> | I do remember people saying that his solutions were naive and didn't account for the realities of the platform as it exists today |
| 15:13 | <gsnedders> | Nobody said that. |
| 15:15 | <jgraham> | Nobody said what? |
| 15:15 | <gsnedders> | That the differences between host and native objects are pure awesome. |
| 15:15 | <gsnedders> | ES6 is totally redefining what host objects do, and limiting what they can do. |
| 15:16 | <jgraham> | Well it can't limit what they can do to less than they actually do do |
| 15:16 | <jgraham> | Or it can but it will be a work of fiction |
| 15:16 | <gsnedders> | jgraham: It already does that. |
| 15:17 | <gsnedders> | jgraham: With stuff like the limitations on property attributes and stuff. |
| 15:17 | <jgraham> | Anyway Alex seems to be attacking a strawman |
| 15:17 | <gsnedders> | I think basically all ES engine APIs allow the host object contract to be violated. |
| 15:18 | annevk | adds comment |
| 15:18 | <annevk> | someone said something like that |
| 15:19 | <annevk> | I think Hixie thought the separation made sense, but I'm not sure to the same extent as Alex makes it seem |
| 15:19 | <annevk> | thought/thinks, dunno, and I've no idea what I think either |
| 15:21 | <jgraham> | I'm pretty sure that the degree to which it was "like that" is less than entirely |
| 15:22 | <jgraham> | Anyway, I agree with your comment that this requires change on the js side as well as the DOM side |
| 15:23 | <gsnedders> | (FWIW, in 2006 ES4 was still going on, so it seems hardly surprising that nothing came of that, when most of the work was basically just rewriting ES3 afterwards) |
| 15:23 | <annevk> | sure there's a ton of explanations why it didn't end up awesome |
| 15:24 | <jgraham> | Sure. The hsitory of the platform is riddled with tragedy and missed oppertunities. |
| 15:24 | <gsnedders> | ES6 will have binary data, at least. |
| 15:24 | <annevk> | I guess we should figure out how to avoid that in the future |
| 15:24 | <annevk> | I still think doing JavaScript elsewhere would help |
| 15:24 | <gsnedders> | The big issue was wasting years on ES4. |
| 15:25 | <gsnedders> | Should we have continued down that route after MS said they wouldn't impl it? Hard to know. |
| 15:25 | <annevk> | prolly |
| 15:25 | <annevk> | MS wouldn't implement XHR2 either |
| 15:25 | <gsnedders> | The market is a very difference place now than then, though, so beckoning to them seems more sensible then than now. |
| 15:26 | <annevk> | or unencumbered fonts |
| 15:26 | <gsnedders> | Still, ES4 was probably too far fetched. |
| 15:26 | <annevk> | XHR2 happened in 2006 too |
| 15:26 | <gsnedders> | It would've taken years to get impls of. |
| 15:26 | <jgraham> | Yeah Microsoft aren't anything special on the web these days. |
| 15:26 | <annevk> | yeah dunno about ES4 either |
| 15:27 | <jgraham> | I'm pretty sure everyone agrees that ES4 has an element of second system syndrone |
| 15:27 | <annevk> | but it doesn't seem to me that ES is being developed with what's needed by APIs |
| 15:27 | <annevk> | at least I hardly get the impression the JavaScript guys look at the platform side much |
| 15:27 | <jgraham> | It isn't clear to me why ES releases have to be huge numbered things |
| 15:27 | <jgraham> | Why not add one feature at a time |
| 15:28 | <gsnedders> | Not only that, but far too much cutting-edge research going into something unproven. |
| 15:28 | <jgraham> | With an overall design arc of course |
| 15:28 | <gsnedders> | jgraham: Depends what changes you want. Syntax changes it makes a fair bit of sense for, you know you either get SyntaxError or you have all of these features. |
| 15:28 | <jgraham> | Well syntax changes are pretty mcuh evil anyway |
| 15:28 | <gsnedders> | *while still being mostly unproven |
| 15:29 | <gsnedders> | jgraham: But if you want to further a language, almost certainly needed. |
| 15:29 | <gsnedders> | What language continues to be developed without syntax changes? |
| 15:29 | <jgraham> | Probably |
| 15:29 | <jgraham> | Given some import mechanism one could allow individual feature to be imported |
| 15:30 | <jgraham> | "use strict;destructuring;let" |
| 15:30 | <jgraham> | and then later |
| 15:30 | <jgraham> | "use v6" |
| 15:30 | <jgraham> | that implies a set of features |
| 15:30 | <gsnedders> | jgraham: The idea as of ES5 was "use strict"; "destructuring"; "let"; |
| 15:30 | <gsnedders> | i.e., each is a separate string |
| 15:30 | <jgraham> | Do you mean 5? |
| 15:30 | <gsnedders> | Yes. |
| 15:31 | <gsnedders> | That was the idea. |
| 15:31 | <gsnedders> | Obviously there was only one pragma then. |
| 15:31 | <jgraham> | Oh. |
| 15:31 | <gsnedders> | In ES6 we just have new semantics within modules and not outwith. |
| 15:31 | <jgraham> | Anyway, more incremental development would be good |
| 15:32 | <gsnedders> | I think most of the limit is getting consensus and editorial resources. |
| 15:32 | <jgraham> | Better communications between the people developing the platform APIs and the language would be good |
| 15:32 | <gsnedders> | And it's not clear how to speed that up. |
| 15:32 | <jgraham> | Well it isn't as much of a problem in HTML/WebApps/etc. |
| 15:33 | <gsnedders> | Yeah, but it's not massively surprising that the language becomes a box, seeming it is a fairly disjoint part of impls, so people tend not to touch so much outwith it, as is the case with DOM and stuff. |
| 15:35 | <Ms2ger> | It's even more fun if you try to spec something inside that box with WebIDL |
| 15:35 | <jgraham> | That isn't entirely true |
| 15:35 | <jgraham> | I mean plenty of people that work on javascript engines alsop work on other parts of the browser |
| 15:36 | <jgraham> | It's just that they're typically not on es-discuss |
| 15:36 | <gsnedders> | jgraham: Outside of Opera, who? |
| 15:36 | <jgraham> | People at Mozilla afaict |
| 15:36 | <jgraham> | Not the major contributers to the ES engine perhaps |
| 15:36 | <gsnedders> | Most of the work on SM comes from people working full time on it. |
| 15:36 | <jgraham> | But people |
| 15:37 | <Ms2ger> | Some JS people work on bindings over here |
| 15:37 | <gsnedders> | Well, sure. But people who only do occasional work on it probably are less inclined to get involved with it. |
| 15:37 | <Ms2ger> | Not many venture out further, though, I think |
| 15:37 | <hober> | Hixie: if you could review http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194 at some point today, that would be awesome. |
| 15:38 | <hober> | Hixie: specifically, i'd like to be able to say something to the effect of " When asked, the editor has indicated that this prose description is unambiguous and detailed enough for him to make the requested changes." :) |
| 15:39 | <hober> | Hixie: also, any other comments / questions / suggestions you might have would be much appreciated. (same goes for the rest of you, of course.) |
| 15:39 | <hober> | the sooner i finish this cp, the sooner i can work on the "defense of canvas v5" cp |
| 15:40 | <Ms2ger> | Or you could get useful work done :) |
| 15:44 | <annevk> | added another comment |
| 15:44 | <annevk> | http://infrequently.org/2012/04/one-for-dave-and-david/comment-page-1/#comment-239690 |
| 16:00 | <jgraham> | I thought that bz did some SpiderMonkey work, sometimes. I though smaug____ was changing the gc recently? |
| 16:00 | <smaug____> | gc? no |
| 16:00 | <smaug____> | I've been hacking cc |
| 16:00 | <jgraham> | Oh, then I misunderstood something |
| 16:00 | <jgraham> | Happens all the time :) |
| 16:01 | <hober> | Ms2ger: that's what the whatwg is for :) |
| 16:02 | <Ms2ger> | jgraham, well, bz... Not all of us can keep all the C++ that goes into Firefox in our heads :) |
| 16:03 | <jgraham> | Right, I didn't say it was normal humans :) |
| 16:15 | <gsnedders> | s/humans// |
| 16:15 | gsnedders | still has no evidence that bz is human |
| 16:16 | <gsnedders> | (Has a physical existance, yes, but not whether he's human.( |
| 16:16 | <gsnedders> | s/\($/)/ |
| 16:16 | <gsnedders> | I really can't type today… |
| 16:16 | <jgraham> | I don't even know what would count as evidence that someone is human |
| 16:17 | <jgraham> | I believe he has managed to procreate successfully? But that could be with another non-human. |
| 16:18 | <gsnedders> | Or could be some weird cross-species thing. |
| 16:21 | <dglazkov> | good morning, Whatwg! |
| 16:31 | <annevk> | http://paul.kinlan.me/dear-appcache/ use #? |
| 16:52 | <gsnedders> | DOM5, defined entirely by a set of ES6 algorithms (as opposed to the English of DOM4)? |
| 16:53 | <gsnedders> | Stuff like making tagName [[Writeable: false]] when it first gets added to the document is trivial in ES, difficult in WebIDL. |
| 16:55 | <annevk> | but I think he got that wrong |
| 16:55 | <MikeSmith> | hsivonen: you around? I wanted to ask you about possibility of using org.whattf.syntax.Driver for command-line validation |
| 16:55 | <annevk> | you don't want it to change ever, because tagName relates to what the object exposes |
| 16:56 | <annevk> | temporal mutability might be nice though; we might have designed events differently i imagine |
| 16:58 | <MikeSmith> | hsivonen: I don't completely understand that code, but it seems like it enables validation without actually running the validator as a web service; if so, it would be great to extend is so it can just take a list of local files as args |
| 17:06 | <MikeSmith> | https://lists.webkit.org/pipermail/webkit-dev/2012-April/020174.html |
| 17:06 | <smaug____> | seriously |
| 17:08 | smaug____ | so much hopes webkit community would fight for the open web |
| 17:10 | <gsnedders> | annevk: R |
| 17:10 | <gsnedders> | *Right, it would involve mutating the [[Prototype] |
| 17:11 | <Ms2ger> | smaug____, Google publishes a draft, Google forces an implementation through, Google uses the feature on their websites... I wonder what these have in common |
| 17:11 | <gsnedders> | Ms2ger: Apple |
| 17:11 | <gsnedders> | Oh, wait, no, the other one! |
| 17:12 | <Ms2ger> | gsnedders, Opera did it fir... I guess not |
| 17:12 | <gsnedders> | Ms2ger: No, that was video. :P |
| 17:12 | <gsnedders> | Until you reach the part of actually shipping a final implementation. |
| 17:12 | <Ms2ger> | Hah, final implementation |
| 17:13 | <gsnedders> | Well… |
| 17:13 | <gsnedders> | You know what I mean. :P |
| 17:14 | <Ms2ger> | Opera did it last? |
| 17:15 | <gsnedders> | Shipping a release with it included. |
| 17:15 | <gsnedders> | We were the first to ship any build with it included, the ones who pushed for the spec… and the last to release. |
| 17:15 | <Ms2ger> | See |
| 17:15 | <Ms2ger> | Don't push for a spec |
| 17:16 | <Ms2ger> | Let someone else write the spec *after* that |
| 17:16 | <Ms2ger> | Like Opera QA |
| 17:16 | <gsnedders> | I think the push for a spec was, "we think a video element would be cool, kthxbai" |
| 17:16 | <gsnedders> | And then people were like "O RLY?" |
| 17:16 | <gsnedders> | And then others were like "YA RLY." |
| 17:16 | <Ms2ger> | Oh, I thought it was "an audio JS object would be cool" |
| 17:17 | <gsnedders> | Oh, no, it was already in the spec by the time we implemented it, and had been for a while. |
| 17:17 | <gsnedders> | Just nobody gave a shit. |
| 17:18 | <gsnedders> | Or at least not to do much about it. |
| 17:26 | <annevk> | gsnedders: if ES6 gets bytes, are they aware of the encoding API? |
| 17:26 | <annevk> | gsnedders: do they envision changes to platform APIs, or are they not looking at it from that perspective? |
| 17:28 | <gsnedders> | annevk: The aim was to get something such that Typed arrays can be redefined in terms of it |
| 17:28 | <gsnedders> | annevk: And I don't think encoding APIs have been discussed |
| 17:29 | <Hixie> | hober: yt? |
| 17:29 | <gsnedders> | annevk: But you'd be better off asking someone actually on TC39 |
| 17:29 | <hober> | Hixie: yo |
| 17:30 | <Hixie> | hober: what's the expected implementation of for=""? |
| 17:30 | <annevk> | gsnedders: I like using you as proxy :) |
| 17:31 | <gsnedders> | annevk: I tend not to speak to anyone on TC39 :P |
| 17:31 | <annevk> | details |
| 17:31 | <Hixie> | hober: (isn't the usual UI going to be going from the video to the transcript, rather than going from the link to the transcript, to the video?) |
| 17:31 | <hober> | the usual ui for usual users would simply be clicking on the transcript link |
| 17:32 | <tantek> | rel=transcript? |
| 17:32 | <hober> | but using for="" allows AT to expose the fact that the video has a transcript associated with it |
| 17:32 | <hober> | tantek: yup |
| 17:32 | <annevk> | can't you do the same trick we do with blockquote |
| 17:32 | <hober> | (and it allows the transcript to be exposed in default and/or custom video controls) |
| 17:32 | <annevk> | paragraph preceding/following with a link that has rel=transcript |
| 17:32 | <Hixie> | hober: so the UA is expected to walk every <a> element in the DOM to look for elements that point to the video? |
| 17:33 | <tantek> | sounds like we're crossing over into media-info microformats like stuff |
| 17:33 | <hober> | Hixie: unfortunately |
| 17:33 | <tantek> | here's a video, a license for it, a transcript, author etc. |
| 17:33 | <Hixie> | hober: that seems like a non-starter |
| 17:33 | <hober> | Hixie: the relationship is many-to-one |
| 17:33 | <hober> | because one media element may have many transcripts |
| 17:33 | <Hixie> | hober: one transcript could apply to many media elements, too :-) |
| 17:33 | <hober> | <video transcript=foo></video...<a id=foo> only lets you point at one |
| 17:34 | <hober> | Hixie: i think that would be a much less common case |
| 17:34 | <Hixie> | hober: if we do this at all, which frankly i think is silly, why not make transcript="" a space-separated idref? |
| 17:34 | <tantek> | make transcript attr multivalued then like class |
| 17:34 | <tantek> | IDRefs |
| 17:34 | <hober> | Hixie: that could work |
| 17:35 | <Hixie> | hober: honestly though this seems like a waste of time, nobody's actually going to use this, and the few who do use it can just use aria-describedby |
| 17:35 | hober | adds that design to the list of considered designs |
| 17:36 | <hober> | Hixie: well, waste of time or not, the CP deadline is today, and the other CP on the table is worse :/ i'm hoping nessy submits a zero-edit "punt this until html.next" CP too; she said she might |
| 17:37 | <Hixie> | hober: if this was a whatwg proposal, i would reject it on the basis of lack of serious use cases and no indication that any implementor was actually going to do anything with it, that <track> already provides what is necessary for accessibility, and that just having a link in the page markup was plenty sufficient to handle the remaining use cases. |
| 17:38 | <Hixie> | hober: honestly i think i prefer the other CP. It is far less invasive and I can easily just put it in the W3C copy and forget about it. |
| 17:38 | <hober> | between <video transcript="url"> and <video transcript="idref idref idref"></video>, which do you prefer? |
| 17:39 | <Hixie> | which is more likely to get implemented? |
| 17:40 | <hober> | i don't know what other UAs plan to do, and we of course don't comment on our future feature plans. :) |
| 17:40 | <annevk> | neither |
| 17:40 | <annevk> | the former is longdesc which is terrible |
| 17:40 | <hober> | that said, <video transcript="url"> suffers from the metacrap problem |
| 17:41 | <annevk> | the latter is for/id name/map stuff which is also terrible and even worse if there's no observable effect |
| 17:41 | <hober> | and <video transcript="idref idref idref"></video> encourages the transcript link to be visible & in prose near the video element, which is where we want people to put these links |
| 17:41 | <Hixie> | it doesn't encourage anything |
| 17:41 | <Hixie> | nobody's gonna use it |
| 17:42 | <Hixie> | people who have transcripts are gonna put them wherever they get the most use of their own accord |
| 17:42 | <Hixie> | and most people aren't gonna have transcripts |
| 17:43 | <hober> | i think putting <video transcript="url"> in the (htmlwg) spec would be damaging, so i'm trying to prevent that. |
| 17:43 | <hober> | one way of preventing that is to simply punt on the problem, which is what nessy's cp will cover (assuming she writes it) |
| 17:44 | <hober> | another way is to try to come up with a design that gets you a programmatic association but that doesn't suffer from the metacrap/longdesc problem |
| 17:46 | <annevk> | is any of the change proposals backed by research into current practice? |
| 17:46 | <annevk> | because if not, a zero change CP is the only way to go |
| 17:46 | <annevk> | cannot add obscure HTML features based on speculation |
| 17:47 | <annevk> | especially if you can get very close using aria-describedby |
| 17:47 | <Hixie> | hober: what would it damage? |
| 17:47 | <hober> | I'd be perfectly happy if my CP lost to a zero-edit CP in the poll |
| 17:48 | <annevk> | why not just make the zero change CP then? |
| 17:48 | <hober> | Hixie: authors would make the same sorts of authoring errors that they make with longdesc="", so ATs & UAs would be more likely to not expose transcript="" by default |
| 17:51 | <Hixie> | hober: if the damage you are concerned about is just "waste authors' time", then rel=transcript causes the same damage. |
| 17:52 | <hober> | heh |
| 17:54 | <webben> | @transcript could be surfaced as an icon in the default video controls |
| 17:55 | <webben> | that video has controls makes the situation somewhat different to img@longdesc |
| 17:56 | <Hixie> | webben: if any user agent actually wants to do that, that changes matters dramatically |
| 17:56 | <Hixie> | webben: i am currently working for the assumption that nobody is actually going to write any code for this stuff. |
| 17:56 | <Hixie> | webben: in which case, my only concern is optimising for minimal impact on the spec. |
| 17:57 | <Hixie> | annevk: yes, if you fullscreen something in an iframe, you have to fullscreen the iframe as well. |
| 17:57 | <MikeSmith> | https://lists.webkit.org/pipermail/webkit-dev/2012-April/020175.html |
| 17:58 | <annevk> | Hixie: mkay |
| 17:58 | <annevk> | Hixie: so the idea is that in Fullscreen we define this new CSS layout thingie? |
| 17:58 | <Hixie> | annevk: (i suggest the UAs do that automatically) |
| 17:58 | <Hixie> | annevk: yeah |
| 17:58 | <annevk> | Hixie: CSS needs maintenance |
| 17:59 | <annevk> | but okay |
| 18:00 | <Hixie> | yeah tell me about it |
| 18:00 | <Hixie> | you volunteering? :-) |
| 18:01 | annevk | looks at fake calendar |
| 18:01 | annevk | suggests 2020 |
| 18:01 | <Ms2ger> | annevk, well, that's before HTML5, so, excellent! |
| 18:02 | <annevk> | oh, I accidentally 10 years |
| 18:02 | <annevk> | I once wanted to define CSS parsing more coherently, but even that I haven't managed to do |
| 18:03 | <MikeSmith> | "actually define how the content is encrypted" vs hand-waving |
| 18:03 | <annevk> | defining the layout true seems so much harder |
| 18:03 | <Ms2ger> | ohunt++ |
| 18:03 | <annevk> | yeah |
| 18:03 | <annevk> | with the Dart debacle too |
| 18:03 | <annevk> | one can count on ohunt |
| 18:03 | <Ms2ger> | annevk, oh, I bet glazou would like it if you started defining layout in a spec whose name doesn't start with "CSS" |
| 18:04 | <gsnedders> | DOM Layout. |
| 18:04 | <annevk> | oh hey look, I'm forking CSS 2.1 Appendix E |
| 18:04 | <hober> | Web Layout :) |
| 18:04 | <gsnedders> | annevk: Can you fork App. H too? |
| 18:05 | <annevk> | Ms2ger: I'm arranging a small bunker in my backyard |
| 18:05 | <Ms2ger> | gsnedders, dammit, I wanted to joke about that, but I had to check which letter it was :( |
| 18:05 | <Ms2ger> | annevk, small? |
| 18:06 | <annevk> | for one person, in case glazou decides to go thermonuclear on this |
| 18:06 | <annevk> | gsnedders: done and done |
| 18:31 | <annevk> | so :fullscreen matches the fullscreen element |
| 18:31 | <annevk> | is there going to be a :modaldialog thing or some such? |
| 18:32 | <Hixie> | <dialog> |
| 18:32 | <Hixie> | er |
| 18:32 | <Hixie> | i guess the selector wouldn't have hte angle brackets! |
| 18:32 | <annevk> | for the non-modal case I guess you might have several dialogs open |
| 18:32 | <Hixie> | yes |
| 18:33 | <Hixie> | those don't end up on the stack |
| 18:33 | <Hixie> | they're just regular abs-pos |
| 18:33 | <annevk> | ah okay, so twitter user profile dialogs end up on the stack, but G+ user profile dialogs don't |
| 18:37 | <Hixie> | G+ user profile dialogs? you mean the hovercard things? |
| 18:37 | <annevk> | yeah |
| 18:38 | <Hixie> | sounds right |
| 18:41 | <annevk> | okay, I'll have a first attempt done somewhere in the next couple of days I hope |
| 18:41 | <rafaelw_> | smaug___: shall we make a call about MutationObserver::take() ? |
| 18:41 | <rafaelw_> | I'd like to start prepping a webkit patch. |
| 18:42 | <rafaelw_> | annevk: also: ^^ |
| 18:42 | <annevk> | takeRecords() ? |
| 18:42 | <annevk> | just take() wfm |
| 18:42 | <annevk> | or maybe releaseRecords() ? |
| 18:42 | <rafaelw_> | i mildly prefer empty() or clear() to take*, but I'll leave it entirely to your & olli's judgement. |
| 18:43 | <smaug____> | release... doesn't sound something which returns the records |
| 18:43 | <Velmont> | Strange behaviour of anne. |
| 18:43 | <annevk> | oops, sorry |
| 18:43 | <smaug____> | rafaelw_: empty() and clear() don't sound like they would return something |
| 18:43 | <rafaelw_> | ;-) |
| 18:44 | <smaug____> | takeRecords() should be pretty clear |
| 18:44 | <annevk> | is there any spec which does something similar? |
| 18:44 | <rafaelw_> | heh. (was just typing the same question). |
| 18:44 | <annevk> | I don't like introducing new patterns, because people always break them |
| 18:44 | <smaug____> | nothing comes to my minds |
| 18:45 | <smaug____> | mind even |
| 18:45 | <rafaelw_> | retrieveRecords() ? |
| 18:45 | <Ms2ger> | A dragon has many minds? |
| 18:48 | <smaug____> | retrieve() or reclaim() ? |
| 18:49 | <annevk> | free() :) |
| 18:49 | <rafaelw_> | i think i prefer retrieve() to take(). are you guys ok with retrieve()? |
| 18:49 | <annevk> | sort of, it's harder to spell |
| 18:49 | <smaug____> | yeah, harder to spell |
| 18:50 | <rafaelw_> | if both you guys want take(), i'll defer to the majority. |
| 18:50 | <annevk> | well, I don't like take either :) |
| 18:50 | <rafaelw_> | annevk: what do you like? |
| 18:50 | <smaug____> | and annevk doesn't like fetch() |
| 18:50 | <Ms2ger> | Don't let Hixie see you, designing things in committee ;) |
| 18:51 | <annevk> | rafaelw_: I haven't been able to come up with anything I really like; takeRecords() seems least problematic thus far |
| 18:51 | <smaug____> | fetchRecords() ? |
| 18:52 | <Ms2ger> | Fentoooon! |
| 18:52 | <Ms2ger> | Ahem |
| 18:52 | <rafaelw_> | sounds like we have a winner. |
| 18:52 | <rafaelw_> | smaug___ ? |
| 18:52 | <smaug____> | takeRecords() ? |
| 18:52 | <annevk> | the annoying thing with fetch is that everything network hangs around that term; that's why I'd like to avoid it |
| 18:52 | <rafaelw_> | yup. annevk: true. |
| 18:52 | <smaug____> | takeRecords() is ok to me |
| 18:53 | <rafaelw_> | i'm fine with takeRecords(). it's not ideal, but i don't have any better ideas. |
| 18:53 | <annevk> | rafaelw_: same here :/ |
| 18:53 | <annevk> | ok lets do takeRecords() |
| 18:53 | <Ms2ger> | Pink |
| 18:54 | <annevk> | feel free to note that in the bug |
| 18:54 | <rafaelw_> | done. |
| 18:54 | <annevk> | it'll be added to the spec within the next couple of days |
| 18:54 | <rafaelw_> | cool. |
| 18:56 | <smaug____> | so, takeRecords() returns a sequence of records |
| 18:56 | <smaug____> | hmm, should the callback have a sequence as a parameter |
| 18:56 | smaug____ | doesn't know if that affects to anything |
| 18:57 | <jwalden> | anyone know if it's possible to load a log page from the krijnlogger with more than a single line highlighted, but not highlighted for everyone? |
| 18:59 | <smaug____> | rafaelw_: should takeRecords() return null or empty array if there are no records |
| 18:59 | <smaug____> | I think empty |
| 18:59 | <rafaelw_> | agree |
| 19:00 | <smaug____> | also, takeRecords() just takes the current records (removes them from the queue), and does nothing else, right? |
| 19:01 | <aklein> | smaug____: re: sequence, I think the callback should technically take a sequence, not an array, though I don't believe it matters at all given that the DOM doesn't hold onto a reference to that argument |
| 19:02 | <smaug____> | aklein: yeah, that is what I was thinking too |
| 19:13 | <annevk> | can make it sequence throughout |
| 19:14 | <annevk> | that's prolly better |
| 19:14 | <annevk> | heycam|away: should a callback be passed a platform array or sequence? |
| 19:14 | <annevk> | heycam|away: might be good to outlaw one of the two |
| 19:16 | <smaug____> | ok, done. Now the boring part, writing tests |
| 19:18 | <Ms2ger> | smaug____, think of it as "finding bugs" :) |
| 19:18 | <smaug____> | that is why we have Jesse |
| 19:19 | <Ms2ger> | Hah |
| 19:26 | <Hixie> | hober: we decided on showModal([anchor]), right? not <dialog modal>? |
| 19:30 | <smaug____> | will showModal work like showModalDialog ? |
| 19:31 | <smaug____> | I assume so |
| 19:31 | <Ms2ger> | Badly? |
| 19:31 | <annevk> | I think the idea was to avoid that |
| 19:33 | <smaug____> | or does the showModal have just callback which is called when the dialog is closed? |
| 19:33 | <smaug____> | s/callback/event dispatched/ |
| 19:33 | <annevk> | I think so |
| 19:33 | <annevk> | anyway, I should sleep and get better |
| 19:33 | <hober> | Hixie: I don't remember; it's in the CP |
| 19:33 | Ms2ger | kicks annevk out |
| 19:34 | hober | digs up the link |
| 19:34 | <Hixie> | smaug____: showModal() just adds an "open" attribute to the <dialog> and prevents anything outside the dialog from being focused or receiving events; the callback is an event fired on the <dialog> itself. |
| 19:34 | <Hixie> | smaug____: it's not like showModalDialog() |
| 19:34 | <rafaelw_> | smaugg___: yes. Just the current records and does nothing else. |
| 19:35 | <Hixie> | hober: i'll go with showModal() |
| 19:35 | <Hixie> | hober: can't work out how to make modal="" work |
| 19:35 | <hober> | Hixie: the CP has <dialog modal> and dialog.show([anchor]) |
| 19:35 | <hober> | Hixie: how is it any harder than showModal()? |
| 19:35 | <Hixie> | what happens if the attribute is removed? |
| 19:36 | <hober> | yeah, fair enough |
| 19:36 | <hober> | i'm surprised we didn't catch that at the time |
| 19:37 | <hober> | with showModal(), how do you style modals differently from non-modals? |
| 19:37 | <hober> | :modal? |
| 19:41 | <Hixie> | you don't |
| 19:42 | <Hixie> | (what's the use case?) |
| 19:44 | <hober> | non-modals often look quite different than modals, but authors can target different dialogs in a variety of ways, so it's no big deal |
| 19:45 | <Hixie> | oh if it's just a matter of looks, then yeah, the class attribute |
| 19:45 | <hober> | fine by me |
| 19:50 | <linclark> | Hixie: do you have a minute for a question about itemref? I'm planning out microdata support for Drupal 8 |
| 19:51 | <Hixie> | sure |
| 19:51 | <linclark> | great, thanks |
| 19:52 | <linclark> | I'm testing an example page with validator nu |
| 19:52 | <linclark> | http://validator.nu/?doc=http%3A%2F%2Flin-clark.com%2Fsites%2Fdefault%2Ffiles%2Fmicrodata.php |
| 19:52 | <linclark> | basically, I'm using itemref for every field, even ones that are nested inside the itemscope |
| 19:52 | <linclark> | Validator NU gives me an error, but it works in Phillips parser and in mine |
| 19:53 | <linclark> | I didn't see anywhere in the spec where it said that itemref-ed elements couldn't be children of the referencing item |
| 19:54 | <linclark> | but I may have missed it |
| 19:54 | <linclark> | or it may be right here: "Properties that are not descendants of the element with the itemscope attribute can be associated with the item using the itemref attribute. " |
| 19:55 | <Hixie> | that sentence isn't normative |
| 19:55 | <Hixie> | but let me look for the normative version |
| 19:56 | <hober> | annevk Hixie: you might find http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-194-6 more to your liking |
| 19:56 | <Hixie> | hober: that certainly works for me :-) |
| 19:58 | <Hixie> | linclark: yeah, it's an error because of the step that says "7. If current is already in memory, there is a microdata error" in the definition of "the properties of an item" |
| 19:58 | <Hixie> | linclark: the error is ignored, so it'll work, but it's non-conforming, because it usually means there was an authoring mistake |
| 19:58 | <Ms2ger> | hober, "experiemental" |
| 19:59 | <linclark> | Hixie: ahh, thanks... do you think it would be poor form for Drupal to handle properties that way? |
| 19:59 | <Hixie> | linclark: it would be poor form for drupal to do something non-conforming, yes :-) |
| 19:59 | <linclark> | Hixie: the problem is that the item doesn't know which of its properties will be displayed inside it |
| 19:59 | <Hixie> | linclark: it's easy to work around, though; just make the itemscope be on a <meta> element |
| 20:00 | <Hixie> | linclark: instead of a <div> |
| 20:00 | <linclark> | Hixie: ok, cool, thanks! |
| 20:00 | <Hixie> | linclark: np |
| 20:00 | <Hixie> | linclark: when designing this we assumed most people would want to mark up subtrees as being a particular item with a bunch of properties, as opposed to having properties all over the place |
| 20:01 | <Hixie> | linclark: which is why this is less than aethetically ideal |
| 20:01 | <Hixie> | linclark: for your case |
| 20:01 | <linclark> | Hixie: that's the assumption that Drupal 7 core makes too, but Drupal 8 is blowing that to pieces |
| 20:01 | <Hixie> | k |
| 20:01 | <hober> | Ms2ger: thanks. i really need to get around to fixing flyspell-mode on this laptop... |
| 20:01 | <Ms2ger> | Np |
| 20:02 | <Hixie> | gotta go, bbiab |
| 20:42 | <eseidel> | ah, Hixie is around :) |
| 21:02 | <jarek> | is there anything like innerHTML for SVG? |
| 21:05 | <jarek> | http://lists.w3.org/Archives/Public/public-html-bugzilla/2012Apr/0051.html |
| 21:05 | <jarek> | says it's should be on Element.prototype, but I can't get it to work on any browser |
| 21:05 | <jarek> | was that introduced just recently? |
| 21:06 | <gsnedders> | jarek: Been in the spec for a while, not implemented |
| 21:07 | <jarek> | should't it be called innerSVG? |
| 21:12 | <roc> | no |
| 21:12 | <roc> | then we'd need innerXML, innerMathML, etc |
| 21:14 | <jarek> | it would make more sense to deprecate innerHTML and introduce innerContent |
| 21:14 | <roc> | not worth it |
| 21:18 | <espadrine> | Hey everyone, the coremob w3c group has released an Acid3-like test bundle for mobile phones at http://www.rng.io/ |
| 21:18 | <espadrine> | Explanation is at https://developers.facebook.com/html5/blog/post/2012/04/04/the-methodology-behind-ringmark/ |
| 21:18 | <espadrine> | Ring 1 intends to test for support of DRM, which is a little controversial (euphemism) but the effort is good |
| 21:23 | <Hixie> | eseidel: wassup? |
| 21:24 | <Hixie> | jarek: what do you mean by "deprecarte"? |
| 21:24 | <Hixie> | "deprecate", even |
| 21:24 | <tantek> | espadrine - so that's the not-so-hidden agenda, an attempt to get DRM interop by way of an acid-test like approach. |
| 21:24 | <jgraham> | espadrine: Well there is no spec for DRM at the moment so I don't see how that will happen |
| 21:24 | <tantek> | 1 DRM Ring to control them all |
| 21:25 | <tantek> | :P |
| 21:25 | <jgraham> | tantek: "DRM ... interop" I'm not sure I follow |
| 21:25 | <tantek> | jgraham - LOL |
| 21:26 | <espadrine> | tantek: if it's any consolation, the spec they are working on states: "codecs are evil. Thoughts?" |
| 21:26 | <jarek> | Hixie: I mean leave innerHTML in the spec for backward compatibility, but introduce new property that would have name that actually makes sense |
| 21:26 | <jgraham> | espadrine: I think that is more Robin than Facebook |
| 21:27 | <Hixie> | jarek: so basically just add another attribute that does the same thing? |
| 21:27 | <Hixie> | jarek: that would just add bloat |
| 21:27 | <jarek> | Hixie: I have even better idea - make SVG part of HTML, then innerHTML would make perfect sense |
| 21:27 | <Hixie> | jarek: SVG is part of HTML. :-) |
| 21:28 | <Hixie> | (for some definition of "part of") |
| 21:28 | <Hixie> | anyway |
| 21:28 | <Hixie> | see /topic |
| 21:28 | <jarek> | Hixie: but it's still XML, you can't write it using HTML grammar |
| 21:28 | <jgraham> | It is disappointing that the blog post talks about "features offered by iOS and Android", since those aren't browsers |
| 21:28 | <Hixie> | yes you can |
| 21:29 | <jarek> | Hixie: you mean when SVG is embeded directly in HTML, I do not have to close SVG tags? |
| 21:29 | <Hixie> | jarek: you have to follow the syntax rules described in the HTML specification |
| 21:30 | <espadrine> | jgraham: true, I assume they meant safari for iOS and Android's default browser |
| 21:30 | <Hixie> | jarek: see http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1450 |
| 21:30 | <eseidel> | Hixie: would like to talka bout <iframe seamless> |
| 21:30 | <Hixie> | eseidel: shoot |
| 21:31 | <eseidel> | Hixie: you intend <iframe seamless> to remain a replaced element, yet "act like" a block, correct? |
| 21:32 | <Hixie> | eseidel: not sure what you mean by "act like a block" |
| 21:32 | <eseidel> | Hixie: it's supposed to fill its parent width |
| 21:32 | <Hixie> | eseidel: it's supposed to do what it says here: http://www.whatwg.org/specs/web-apps/current-work/#attr-iframe-seamless |
| 21:32 | <jgraham> | espadrine: Probably. Not a very healthy attitude that the only browser that matters is the one that ships with the device. Too much like designing only for IE. |
| 21:32 | <eseidel> | yup, i'm aware :) |
| 21:32 | <Hixie> | eseidel: which, as far as width goes, means "In visual media, in a CSS-supporting user agent: the user agent should set the intrinsic width of the iframe to the width that the element would have if it was a non-replaced block-level element with 'width: auto'." |
| 21:33 | <jarek> | is there any hope that the baseVal/animVal stuff will be dropped from SVG2 spec? |
| 21:33 | <eseidel> | Hixie: this is thus unaffected by the display type |
| 21:33 | <eseidel> | so iframe.style.display should remain "inline" |
| 21:34 | <jarek> | it breaks pretty much all HTML DOM frameworks like jQuery |
| 21:34 | <eseidel> | Hixie: and I assume, that it should shrink-wrap, as a block would, when floated |
| 21:34 | <Hixie> | eseidel: iframe.style.display returns the value specified in the style="" attribute, so typically it will remain the empty string |
| 21:34 | <eseidel> | Hixie: sory, window.getComputedStyle(iframe).display then :) |
| 21:34 | <jgraham> | jarek: Did you send feedback to the wg? |
| 21:36 | <Hixie> | eseidel: if you float it, then "the width that the element would have if it was a non-replaced block-level element with 'width: auto'" would be zero, presumably |
| 21:36 | <Hixie> | eseidel: though i think that could probably be better defined |
| 21:36 | <eseidel> | Hixie: when you float a block, it shrink wraps around its kids, is my understanding |
| 21:36 | <eseidel> | that's the behavior I've currently implemented |
| 21:36 | <Hixie> | eseidel: the iframe has no kids |
| 21:36 | <Hixie> | eseidel: if it's not replaced |
| 21:36 | <ojan> | Hixie: that's gross |
| 21:37 | <ojan> | Hixie: it should shrink-wrap! |
| 21:37 | <Hixie> | ojan: i'm not talking about what a good design should be, i'm just answering questions about what the spec says today |
| 21:37 | <eseidel> | Hixie: that's fine, those are the qeustions I'm answering :) |
| 21:37 | <ojan> | Hixie: oh sure...i was telling eseidel that the spec should change |
| 21:37 | <eseidel> | askgin, rather |
| 21:37 | <Hixie> | ojan: i'm happy to talk about changing what the spec says, but that's a different conversation :-) |
| 21:37 | <ojan> | Hixie: fair enough |
| 21:38 | <eseidel> | Hixie: so your interpretation of the currnet spec, is that when floated the width shoudl be 0 |
| 21:38 | <Hixie> | ojan: (i think you're probably right that it should change) |
| 21:38 | <Hixie> | eseidel: well, the current spec actually says something which as ojan says is pretty dumb, which is that its contents, namely the fallback markup between the <iframe></iframe> tags, would be shrink-wrapped |
| 21:38 | <eseidel> | is ee. |
| 21:38 | <Hixie> | eseidel: typically that's empty so it would be zero width |
| 21:39 | <eseidel> | ojan was suggeting earlier an interpretation would be to just force iframe to be display: block in this mode |
| 21:39 | <ojan> | Hixie: i think the computedStyle of display on <iframe seamless> should be block and that we should pretend that the iframe's contentDocument's children are it's children |
| 21:40 | <Hixie> | eseidel: 'float' forces display:block anyway |
| 21:40 | <eseidel> | ojan: obviously you don't mean firstChild spanning docs :) |
| 21:40 | <eseidel> | Hixie: correct |
| 21:40 | <ojan> | Hixie: and that you should be able to do <iframe seamless style="display:inline-block"> to get a shrink-wrapped seamless iframe |
| 21:41 | <ojan> | Hixie: and in that case the computedstyle would obviously be display:inline-block |
| 21:41 | <Hixie> | ojan: well it needs to be a replaced element |
| 21:41 | <Hixie> | ojan: whether it's block or inline doesn't much matter, i don't see why we wouldn't just leave it be what the author set it to |
| 21:41 | <ojan> | Hixie: i'm not really sure what the implications of being replaced are |
| 21:41 | eseidel | neither |
| 21:41 | <ojan> | Hixie: it seems more consistent with e.g. coerciing display of a floated element to block |
| 21:41 | <Hixie> | see http://www.w3.org/TR/CSS21/visudet.html |
| 21:42 | <Hixie> | e.g. 'width' doesn't apply to non-replaced inline elements |
| 21:42 | <Hixie> | 'padding' doesn't apply to replaced block elements |
| 21:43 | <Hixie> | basically anything that's like an image or form control is replaced |
| 21:43 | <Hixie> | anyway |
| 21:43 | <Hixie> | i agree that shrink-wrapping the contents makes sense if the element is unconstrained |
| 21:43 | <Hixie> | spec needs to change to say that |
| 21:43 | <Hixie> | can you file a bug or send mail to whatwg? |
| 21:44 | <ojan> | sure |
| 21:44 | <Hixie> | awesome, thanks |
| 21:44 | <Hixie> | (looks like i just didn't think of the case of a seamless iframe not being in flow) |
| 21:46 | <Hixie> | specifically i think the spec needs to say that for in-flow, block-level seamless iframes, the width is the width of the containing block minus the inline-progression-direction margins and borders |
| 21:47 | <Hixie> | and that for other cases, the width is the intrinsic width of the root element's box in the document in the iframe |
| 21:47 | <Hixie> | or some such |
| 21:47 | <eseidel> | Hixie: further clarification would certainly be helpful :) |
| 21:48 | <ojan> | Hixie: by deafult, iframe's are display:inline, right? so...by that definition, to get display:block style rendering you'd need to set seamless and display:block, no? |
| 21:49 | <ojan> | Hixie: is intrinsic width == shrink-wrapped width? |
| 21:49 | <eseidel> | ojan: it's unclear what display: block would change, other than the max-width interaction |
| 21:49 | <ojan> | eseidel: inlines don't fill their containers width |
| 21:49 | <eseidel> | ojan: except seamless iframes, hack their way into doing so |
| 21:49 | <eseidel> | ojan: unless constrained by max-width |
| 21:50 | <Hixie> | ojan: yeah, you'd need to set display:block if you wanted the iframe to act like a block |
| 21:50 | <ojan> | eseidel: i'm just commenting on Hixies use of "block-level" above...by default iframe's aren't block-level |
| 21:50 | <Hixie> | ojan: otherwise it'll just sit on the line (like an inline-block, more or less) |
| 21:50 | <ojan> | Hixie: hm...not sure how i feel about that...i guess that's ok |
| 21:50 | <eseidel> | ojan: I need to write a test for what happens when <iframe seamless style="max-width: "> is on a line, that it doesn't force the other content on that line to the next line |
| 21:51 | <Hixie> | ojan: "intrinsic width" is an input into the css model. "shrink-wrapped width" is a nebulous concept I'd have to define better. |
| 21:51 | <ojan> | Hixie: but it seems by far the common case will that be people will want display:block |
| 21:51 | <Hixie> | ojan: that's usually the case with iframes in general |
| 21:51 | <ojan> | Hixie: would you be opposed to adding iframe[seamless] { display: block } to the UA stylesheet? |
| 21:52 | <ojan> | Hixie: btw, i'll put all this in an email to whatwg@ when we're done. |
| 21:52 | <Hixie> | ojan: not overly opposed, but it's yet more magic, which is often a bad sign |
| 21:53 | <ojan> | Hixie: ok...i'll send an email...we'll see what others think |
| 21:53 | <ojan> | Hixie: i dont' feel strongly about this...i'm on the fence...but it seems like it is what developers will want 90% of the time |
| 21:54 | ojan | goes to compose this email |
| 21:54 | <ojan> | sigh...i was going to write code today :( |
| 21:54 | <Hixie> | ojan: well like i said, i think it's what they want 98% of the time with <iframe> regardless of seamless |
| 21:55 | <ojan> | Hixie: sure...but they can't have it with non-seamless iframes :) |
| 21:55 | <ojan> | Hixie: oh...i guess they could if not for back-compat issues |
| 21:55 | <Hixie> | they can just set iframe { display: block; width: 100%; border: 0; } |
| 21:55 | <Hixie> | in their CSS |
| 21:55 | <ojan> | yeah |
| 21:55 | <Hixie> | just like with seamless ones :-) |
| 21:55 | <Hixie> | we don't turn off teh default border on iframe[seamless] either, do we? |
| 21:56 | <ojan> | Hixie: we should! |
| 21:56 | <Hixie> | and i guarantee they don't want that |
| 21:56 | <ojan> | Hixie: in a sense it's more magic...in another sense...when you're explaining how seamless works to someone...you can say that it roughly makes an iframe act like a div |
| 21:57 | <Hixie> | i'm not especialy opposed |
| 21:57 | <ojan> | Hixie: also if only width:100% did the right thing! |
| 21:57 | <Hixie> | i think the argument is more compelling if we also turn off the border |
| 21:57 | <ojan> | Hixie: as in...in the presense of padding |
| 21:57 | <ojan> | Hixie: i agree |
| 21:57 | <ojan> | Hixie: and i think we should |
| 21:57 | <Hixie> | oh actually we do |
| 21:57 | <Hixie> | iframe:not([seamless]) { border: 2px inset; } |
| 21:58 | <eseidel> | ha |
| 21:58 | <eseidel> | webkit doesn't have tha tyet |
| 21:58 | <eseidel> | but I'l add it |
| 21:58 | <eseidel> | I had to turn it off manually in my tests |
| 21:59 | <Hixie> | that's pretty buried in the spec, not surprised you missed it |
| 22:00 | <abarth> | eseidel: we have -webkit-not |
| 22:00 | <abarth> | I think ojan implemented it |
| 22:01 | <Hixie> | why -webkit-? |
| 22:01 | <Hixie> | :not() is ancient |
| 22:01 | <ojan> | abarth: no...i had a patch up for extending it, but we've had :not for ages |
| 22:01 | <ojan> | abarth: my patch bit-rotted and never landed though |
| 22:01 | <abarth> | ah, ok |
| 22:01 | <ojan> | abarth: the latest selectors spec has it take a comma separated list instead of a single selector |
| 22:02 | <ojan> | abarth: but there's a bunch of tests out there that enforce that it take a single selector |
| 22:02 | <abarth> | maybe I misunderstood what eseidel meant |
| 22:02 | <ojan> | abarth: and i wasn't able to get the test authors to change their tests (or respond to my emails at all) |
| 22:02 | <ojan> | abarth: the whole thing is pretty lame |
| 22:02 | <ojan> | abarth: yeah...not sure what eseidel is saying |
| 22:02 | <ojan> | that should work |
| 22:03 | <ojan> | oh, i think he's just saying that we havne't added that to the UA stylesheet yet |
| 22:03 | <ojan> | eseidel: we need to be careful how we add that bit since :not and [seamless] are both super expensive |
| 22:05 | <eseidel> | abarth, ojan, I was noting that our html.css rule is simpler |
| 22:05 | <eseidel> | no :not([seamless]) |
| 22:05 | <eseidel> | ojan: how super-expensive? |
| 22:05 | <eseidel> | ojan: you think that adding that qualifier will show up in the plg? |
| 22:05 | <eseidel> | plt |
| 22:06 | <ojan> | eseidel: might. not sure |
| 22:06 | <ojan> | eseidel: antti would have a better sense of the perf implications. |
| 22:06 | <eseidel> | ojan: I'm just going to be naive :) |
| 22:07 | <ojan> | eseidel: but there are def cases where we don't use CSS for attribute/not selectors and instead use C++ code to make the style be correct because of the perf issues |
| 22:07 | <ojan> | eseidel: anyways...we should probably stop spamming whatwg with webkit implementation details :) |
| 22:07 | <eseidel> | ojan: k |
| 22:07 | <eseidel> | ojan: I appreciate the warning |
| 22:07 | <eseidel> | ojan: oh, sorry, thought we wer ein #webkit |
| 22:08 | <Hixie> | you're welcome to spam the channel with implementation details |
| 22:08 | <Hixie> | it prevents us from climbing the ivory tower |
| 22:24 | <roc> | I would expect ":not([seamless])" to be ultra-expensive and "iframe:not([seamless])" to be very inexpensive |
| 22:29 | <Hixie> | i don't suppose anyone wants to spec me an 'anchor-point' CSS property and its corresponding logic |
| 22:30 | <Hixie> | for someone who left the css working group i sure seem to end up inventing a lot of css stuff |
| 22:32 | <tantek> | inventing or depending on? ;) |
| 22:32 | <Hixie> | inventing and speccing |
| 22:33 | <Hixie> | TabAtkins: do i have to do anything special with respect to transitions, style canonicalisation and serialisation, CSSOM, etc, if I create a new property? Or is the CSS2.1 style of property definition still the state of the art? |
| 22:33 | <tantek> | the latest state of the art for that is in the CSS spec template |
| 22:34 | <roc> | what does anchor-point do? |
| 22:34 | <tantek> | for animation just say animatable:no until someone comes up with a use-case :) |
| 22:35 | <hober> | i assume anchor-point is for positioning non-modal dialogs |
| 22:35 | <tantek> | the point which things can be position:center'd relative to presumably |
| 22:35 | <Hixie> | roc: defines which point in one box should be aligned with which point in another box when you show a non-modal dialog aligned with another element |
| 22:35 | <tantek> | Hixie, here is said CSS spec template: http://dev.w3.org/csswg/css-module/Overview.src.html |
| 22:35 | <Hixie> | roc: (consider the "tooltip"-like popup windows with arrows that point to new features in web apps these days) |
| 22:35 | <Hixie> | tantek: thanks |
| 22:36 | <roc> | how are you going to reference another box? how are you going to deal with cyclic dependencies? |
| 22:36 | <tantek> | also - that template is not frozen - please feel free to make suggested improvements etc. |
| 22:36 | <Hixie> | tantek: is there any documentation about what the various liens mean? |
| 22:37 | <Hixie> | roc: the first box is the <Dialog> element, that's the one being positioned, and the box to which you are anchoring is the argument to the show() method |
| 22:37 | <Hixie> | tantek: lines, even |
| 22:37 | <Hixie> | tantek: specifically "Animatable" and "Canonical order" |
| 22:38 | <roc> | oh, so the target box/element isn't specified in the CSS rule, but is implicit DOM state? |
| 22:38 | <tantek> | Hixie, let's see, this helps for computable: http://wiki.csswg.org/spec/computed-values |
| 22:38 | <Hixie> | roc: yeah. might be explicit DOM state, haven't figured that out yet. |
| 22:39 | <tantek> | Hixie, I couldn't find docs for those lines either, hence omitted them from CSS3-UI LCWD2 until someone steps up to define them. This action was not appreciated by the wg (or at least some members thereof) |
| 22:39 | <tantek> | This has some additional guidance: http://wiki.csswg.org/spec/format-update |
| 22:39 | <Hixie> | tantek: heh |
| 22:40 | <Hixie> | tantek: so how do i specify how a transition between two values works? |
| 22:40 | <tantek> | since then I've decided I can just put "animatable: no" until someone complains and then I can make them document real world use-cases |
| 22:40 | <tantek> | great question |
| 22:41 | <Hixie> | i'm assuming "great question" is the usual euphemism for "you have stepped into a political landmine, please wait while i step out of the way" :-P |
| 22:41 | <tantek> | "great question" means AFAIK no well defined answer |
| 22:42 | <Hixie> | ok i found documentation for the "animatable" line: http://www.w3.org/TR/css3-transitions/#animatable-properties |
| 22:42 | <tantek> | political landmines are much "easier" to deal with as all you have to do is trigger them and then analyze the results |
| 22:42 | <tantek> | I believe tabatkins has had to address that question in flexbox so he may be able to help |
| 22:46 | <zewt> | are there any political unit tests |
| 22:50 | <tantek> | zewt, it's not clear it is possible to construct political unit tests as such test cases typically involve a lot of context (thus not "unit"), and political user agents also typically exhibit an observer effect, making tests not necessarily repeatable. http://en.wikipedia.org/wiki/Observer_effect_%28physics%29#Social_sciences |
| 22:51 | <zewt> | you need fixtures that reproduce the responses of other entities in the system |
| 22:52 | <tantek> | or the ability to reset a political user agent to a previous state or a known initial state |
| 22:52 | <zewt> | transactional users |
| 22:54 | <zewt> | like when you mention something as a "here's an idea but it's a really bad one" aside, then people LATCH ONTO IT and you just wish you could rollback to before you even mentioned it |
| 22:57 | <tantek> | unless your intention was to honeypot such folks into being distracted by it |
| 23:05 | <Hixie> | i can't work out what is expected for the "canonical order" line |
| 23:05 | <Hixie> | it seems to me what is needed isn't a canonical order but a canonical serialisation |
| 23:08 | <tantek> | like every property should specify its canonical DOM serialization? |
| 23:11 | <Hixie> | well for most properties it follows straight from the grammar |
| 23:11 | <Hixie> | but occasionally there are complications, yeah |
| 23:11 | <Hixie> | i'm assuming that's what this line is about |
| 23:14 | <Hixie> | bbl |
| 23:22 | <heycam> | annevk, I would use a sequence if you just want a JS Array object to be passed to the callback, and an array type if you want the callback to be able to modify the array and the DOM object to be able to notice that |
| 23:53 | <zewt> | heycam: sequence vs. array must be in the top three of idl things people get confused about, heh |
| 23:53 | <heycam> | zewt, definitely |
| 23:53 | <heycam> | might have been better to use a word other than "array" for array types |
| 23:54 | <zewt> | is it basically the difference between returning a vector<int> vs. an int*? |
| 23:54 | <heycam> | pretty much, except that with the int* case the DOM object can also notice when you set values, change the array length, etc. |
| 23:54 | <heycam> | it's much more like an object with indexed properties and a length property |
| 23:54 | <zewt> | does it "notice", or does it have to compare after the fact? |
| 23:55 | <heycam> | well I would say that it can notice |
| 23:55 | <zewt> | eg. does it effectively override the setter, so it can detect changes immediately, or is it more like keeping a copy of the original data and comparing afterwards |
| 23:56 | <heycam> | yeah the former |
| 23:56 | <zewt> | (the former being quicker for large sets of data, but presumably with more overhead to JS) |
| 23:56 | <heycam> | because if you have an IDL attribute of type whatever[], then you can manipulate it and the DOM object can respond immediately |
| 23:56 | <zewt> | (well, more memory efficient, I should say) |
