| 00:00 | <zewt> | whatever the "w3c technical architecture group" is, this "comment" on web storage/app cache is not making them appear terribly ... *cough* on top of things |
| 00:02 | <zewt> | it's almost as if they ignored web storage while it was out in production for years, waiting until it's going to LC to even bother looking at it |
| 01:02 | <zcorpan> | zewt: what do you mean "as if" |
| 01:02 | <zcorpan> | hmm. past bedtime. nn |
| 01:17 | <tantek> | oops just saw Hixie's yt |
| 01:18 | <tantek-ipod> | Now here as tpod also |
| 01:18 | <tantek> | oh look at that |
| 02:14 | <zewt> | bluh |
| 02:14 | <zewt> | there's that other glenn :| |
| 03:23 | <roc> | TabAtkins: I'm just going to send our proposed list of properties to www-style right now |
| 04:00 | <roc> | well, that should generate some discussion |
| 04:04 | <zewt> | should I fear |
| 04:04 | <zewt> | i guess not, since i don't follow www-style |
| 04:53 | <Hixie> | aww, missed tantek |
| 07:43 | <Ms2ger> | Philip`, isn't this a nice day to work on canvas tests? :) |
| 07:45 | <Margle> | ok, so I've asked this before… but this channel… do you guys know each other? |
| 07:45 | <Margle> | do you work in the industry? |
| 07:47 | <Hixie> | margle: most people here have some relationship to browser vendors, standards organisations, or the like |
| 07:47 | <Hixie> | margle: we haven't all met in person though |
| 07:47 | <margle> | radsauce |
| 07:53 | <hsivonen> | XHR Level 2 FTW! HTML in XHR support landed. |
| 07:54 | <hsivonen> | (I'll write a report to public-webapps about the implementation choices.) |
| 08:31 | <Ms2ger> | required_props.code = { ... }[code]; required_props[code] = required_props.code; |
| 08:31 | Ms2ger | is confused |
| 09:22 | <jacobolus> | is it possible to stick an https page in an iframe on a page at a different domain? I don't want to communicate between the frames, I just want to show its content in a box |
| 09:27 | <zcorpan> | sure |
| 09:28 | <jacobolus> | oh, nevermind |
| 09:28 | <zcorpan> | but if it has an insecure cert or so it won't be shown in some browsers |
| 09:28 | <jacobolus> | there's an x-frame-options header :) |
| 09:28 | <jacobolus> | that explains it |
| 09:29 | <jacobolus> | is that part of any specific spec? |
| 09:42 | <zcorpan> | it appears no |
| 09:43 | <zcorpan> | added to http://wiki.whatwg.org/wiki/Specifications_TODO |
| 10:16 | <annevk> | I like how glazou wrote his post starting from the assumption he would disagree with hsivonen and never really evaluates his position |
| 10:18 | <jgraham> | Are you surprised? |
| 10:19 | annevk | assumes rhetorical |
| 10:19 | <hsivonen> | annevk: to me, it seems that at some points glazou effectively says that the CSS WG's policies aren't to blame but the browser vendors that comply with the policies |
| 10:26 | <annevk> | Which is not just ironic for that reason, it's also ironic because the reason this feature was originally designed for. And he seems ignorant about early IE, not that it matters... |
| 10:29 | <annevk> | I think we should just do what is right and have the few people in the CSS WG who think the current crazy is right, adjust |
| 11:11 | <annevk> | stevef: if you read this, *both* probably require changes; not either fullscreen or modal dialogs |
| 11:11 | <annevk> | stevef: so yes, someone has to look into it, probably someone who knows a lot about stacking contexts and layout fun |
| 11:13 | <annevk> | stevef: also, TabAtkins wrote the CCP for ISSUE-134, not sicking |
| 11:28 | <gsnedders> | It seems glazou's argument basically makes sense if stuff moves to CR as soon as its stable. |
| 11:28 | <gsnedders> | On a per-feature basis. |
| 11:29 | <annevk> | wait |
| 11:29 | <annevk> | you mean like how HTML living standard works? |
| 11:29 | <annevk> | because like you know, he dislikes that |
| 11:30 | <gsnedders> | No. |
| 11:30 | <gsnedders> | Just split each CSS feature out into a module of its own as soon as it is ready to go to CR. |
| 11:31 | <gsnedders> | Doing that allows you to have a model consistent with what glazou is arguing and what browser vendors want, I think. |
| 11:31 | <gsnedders> | I think that's the only model that has that quality, though. |
| 11:32 | <jgraham> | Ah the infinite editorial work model |
| 11:33 | <annevk> | good luck finding people happy to work on that |
| 11:33 | <jgraham> | Anyway I think that doesn't work unless the CSSWG use the same definition of "stable" as the rest of the world |
| 11:33 | <gsnedders> | On a totally unrelated note, both IE9 and Opera 11.10/Windows limit timer resolution to 60Hz while running on battery to minimize CPU usage — I wonder if that's worth making conforming behaviour… |
| 11:34 | <gsnedders> | Or is that already conforming? |
| 11:34 | <gsnedders> | Hmmm… |
| 11:36 | <gsnedders> | Informative note claims that is conforming, but I'm not sure I understand how. |
| 11:38 | <annevk> | http://happyworm.com/blog/2011/11/15/html5-audio-apis-how-low-can-we-go/ "I would strongly urge the developers of it to include a more comprehensive low level API in future releases. What’s the worst that could happen?" *chuckle* |
| 11:41 | <jgraham> | gsnedders: Hardware limitations clause |
| 11:41 | <gsnedders> | jgraham: It's not a hardware limitation though. I can perfectly well get nanosecond percision from the hardware, I just choose not to. |
| 11:42 | <jgraham> | gsnedders: The fact that it will kill the battery unreasonably fast is a hardware limitation |
| 11:42 | <annevk> | roc: should fullscreenerror also dispatch only on Document? |
| 11:43 | <gsnedders> | "User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations." |
| 11:43 | <annevk> | roc: made that change for now |
| 11:43 | <gsnedders> | It's not an otherwise unconstrained input, it's constrained to 4ms. |
| 11:43 | <gsnedders> | So that clause doesn't apply. |
| 11:44 | <annevk> | gsnedders: so your point is that clause should be reworded? |
| 11:45 | <gsnedders> | annevk: My point is we have multiple impls that disagree with the spec that don't intend on changing behaviour so the spec should change. |
| 11:45 | <gsnedders> | I don't really care how the normative change is made. |
| 12:14 | <zcorpan> | gsnedders: iirc the spec allows for arbitrary delay in timers |
| 12:15 | <zcorpan> | Optionally, wait a further user-agent defined length of time. |
| 12:15 | <zcorpan> | This is intended to allow user agents to pad timeouts as needed to optimise the power usage of the device. For example, some processors have a low-power mode where the granularity of timers is reduced; on such platforms, user agents can slow timers down to fit this schedule instead of requiring the processor to use the more accurate mode with its associated higher power usage. |
| 12:16 | <gsnedders> | does "user-agent defined" mean it have to be constant? |
| 12:16 | <zcorpan> | why would it? |
| 12:31 | <gsnedders> | In other news, TabAtkins: happy birthday! |
| 12:35 | <bga_> | +1 |
| 13:45 | <annevk> | eh |
| 13:45 | <annevk> | speccing stacks |
| 13:45 | <annevk> | :( |
| 14:05 | <AryehGregor> | jgraham, I don't really care where the patches are stored prior to review. They can be somewhere other than a branch, that's fine by me. |
| 14:08 | <jgraham> | AryehGregor: The point is commit-to-branch-then-review gives you the benefits of version control for your unrevieweed changes. For example a new commit to the same branch represents a fix to the previous commits to address review comments or fix bugs |
| 14:09 | <AryehGregor> | Possibly. |
| 14:09 | <AryehGregor> | Unrelated: what browsers need to do is have on-by-default instrumentation that sends back info to the browser vendor in a manner that doesn't breach user privacy. |
| 14:09 | <AryehGregor> | For instance: |
| 14:10 | <AryehGregor> | If you want to know for what percentage of users a boolean B is true, send back a bit computed as follows: with probability 0.99999, send a random bit. With probability 0.00001, send B. |
| 14:11 | <annevk> | AryehGregor: fwiw, I have filed several bugs on Gecko regarding removing redundant/obsolete for which Ms2ger provided patches that are now removed from the platform |
| 14:11 | <annevk> | AryehGregor: you could do the same |
| 14:12 | <AryehGregor> | Then add all the received bits together, divide by the number of bits, subtract 0.444445, multiply by 100,000. |
| 14:12 | <AryehGregor> | If you have enough users, that should give you the correct percentage of users for which B is true. |
| 14:13 | <AryehGregor> | But for any given user, the bit is 99.999% likely to be noise, so it yields negligible information. |
| 14:13 | <AryehGregor> | Submit all these bits back every time you check for an update. |
| 14:13 | <AryehGregor> | That would be incredibly useful data at no cost to privacy. |
| 14:14 | <AryehGregor> | You could submit the value of every boolean pref, and also things like "was Range.detach() called by any page since the last update". |
| 14:14 | <AryehGregor> | For that matter, you could just throw in whether every single JS-exposed method was called since the last update. |
| 14:15 | <AryehGregor> | Thereby gaining a list of methods that are effectively never used. |
| 14:15 | <AryehGregor> | Wouldn't it be great if we had data like that? |
| 14:16 | <annevk> | sure |
| 14:19 | <AryehGregor> | https://bugzilla.mozilla.org/show_bug.cgi?id=702948 |
| 14:44 | <AryehGregor> | Okay, why does this throw an exception? [""].map("".trim) |
| 14:44 | <AryehGregor> | But "".trim.call("") does not. |
| 14:45 | <bga_> | in 1st case use pass {window} as {this} |
| 14:45 | <AryehGregor> | Why is that necessary? |
| 14:45 | <bga_> | {window} is not string |
| 14:46 | <AryehGregor> | Oh. |
| 14:46 | <AryehGregor> | Hmm? |
| 14:46 | <AryehGregor> | I don't get it. |
| 14:46 | <AryehGregor> | The function is called on the array elements, no? |
| 14:46 | <AryehGregor> | Oh. |
| 14:46 | <AryehGregor> | No, I still don't get it. |
| 14:47 | <bga_> | you want trim(arguments[0]) |
| 14:47 | <bga_> | but native trim is str.trim(), not trim(arg) |
| 14:48 | <AryehGregor> | Oh, right. |
| 14:48 | <AryehGregor> | It's operating on the this value, not on the first argument. |
| 14:49 | <AryehGregor> | So really I need [""].map(function(s) { return s.trim() }). |
| 14:49 | <AryehGregor> | Okay. |
| 14:49 | <AryehGregor> | Awkward, but makes sense now. |
| 15:01 | <hsivonen> | foolip: thanks for the typo notification on G+. Fixed. |
| 15:02 | foolip | is a bit sad to see the CSS WG co-chair "totally disagree and will do all I can to avoid that" |
| 15:04 | <annevk> | W3C TAG is pretty sad state of affairs too |
| 15:04 | <Rik`> | I thought co-chairs shouldn't express their opinions as co-chairs |
| 15:04 | <annevk> | Art is cool (co-chair WebApps) |
| 15:07 | <annevk> | Rik`: http://www.w3.org/2005/10/Process-20051014/process.html#GeneralChairs defers to a Member-only document with respect to the roles of a Chair |
| 15:08 | <annevk> | Rik`: but yes, one of the rules that is pretty widely known is that a Chair removes his "Chair-hat" when participating in a discussion |
| 15:09 | <annevk> | Rik`: not sure what the practical difference is though |
| 15:10 | <Rik`> | every time glazou talks about CSS, he mentions his role as co-chair instead of member |
| 15:11 | <Rik`> | that kind of implies that he has a bigger voice for decisions |
| 15:19 | <Philip`> | A chair hat sounds like it could cause serious spinal injuries |
| 15:20 | <wilhelm_> | That would explain a lot. |
| 15:22 | <zcorpan> | i read on google plus earlier that they care about page load speed. now when i'm on the train i can't load google plus at all, but facebook and twitter load fine |
| 15:22 | <annevk> | don't believe everything you read? :p |
| 15:23 | <zcorpan> | that doesn't help me with getting it loaded :) |
| 15:25 | <jgraham> | Use the time to try and beat your social networking addiction? |
| 15:26 | <Rik`> | I've heard wordpress loads fine |
| 15:27 | <zcorpan> | i just wanted to read the comments on Hixie's <time> post, but plus wants me to do something else clearly |
| 15:33 | <jgraham> | zcorpan: I have now read them for you. TLDR: blah blah, whine, moan, WHATWG is evil, blah |
| 15:35 | <gavinc> | jgraham: by that summary I guess Ian's post was blah blah, whine, moan, W3C is evil, blah |
| 15:39 | <foolip> | gavinc, almost exactly, yes: https://plus.google.com/107429617152575897589/107429617152575897589/posts/3ZEQAVkF6xd |
| 15:39 | <gavinc> | foolip: yeah, I have read... and commented |
| 15:42 | <jgraham> | gavinc: Plus a couple of sentences of useful information, yeah |
| 15:42 | <hsivonen> | It sucks that Hixie does stuff like the <time> removal. stunts like that make people more afraid of Living Standards and makes it harder to advocate changes to the way the CSS WG does stuff |
| 15:43 | <hsivonen> | s/and/which/ |
| 15:43 | <foolip> | hsivonen, do you think it was obvious from the initial bug that removing it was a bad idea? |
| 15:47 | <hsivonen> | foolip: politically, yes. I think I'm going to stay out of the technical debate for a while still. |
| 15:47 | <jgraham> | hsivonen: It seems to me that characterising it as a "stunt" is unfair. It also seems to me that the new use cases (the ones I head orally; I haven't checked the wiki page) are pretty shaky; in particular the value to a search engine of a <time> with no context about what type of time it is seems rather small. But I am happy to accept that the risk of including the element is small compared to the chance of it being useful |
| 15:47 | <hsivonen> | (the political side matters as far as making people scared of Living Standards) |
| 15:47 | <hsivonen> | jgraham: ok. maybe calling it a "stunt" is unfair. sorry |
| 15:48 | <foolip> | sure, it's completely unsurprising that some people got upset |
| 15:49 | <annevk> | thanks for your XHR email hsivonen |
| 15:49 | <annevk> | hsivonen: not sure when I get to it yet |
| 15:49 | <annevk> | hsivonen: all these little patches to specs all over is taking its time |
| 15:58 | <hsivonen> | annevk: ok. it will be interesting to see how badly non-null responseXML for error responses breaks the Web |
| 16:04 | <zcorpan> | http://www.google.com/codesearch#search/&q=%5C.responseXML%5Cs*%5C!?===?%5Cs*null&type=cs |
| 16:05 | <zcorpan> | there you can see a few sites to test, like fckeditor |
| 16:06 | <AryehGregor> | Ugh, why does rdesktop to an EC2 Windows instance require a million tries before it works? |
| 16:06 | <Ms3ger> | http://www.google.com/codesearch#search/&q=\.responseXML\s*[\!=]==?\s*null&type=cs might work better |
| 16:14 | karlcow | sees the "public domain" license on http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html and wonders about the implication with French law. |
| 16:14 | <karlcow> | I guess it doesn't matter given the nationality of the two editors. No idea. |
| 16:14 | <karlcow> | Doomed copyright laws. |
| 16:19 | <annevk> | karlcow: CC0 1.0 should work no? (which is what it is) |
| 16:20 | <annevk> | smaug____: should we prevent sync for cross-origin requests entirely? |
| 16:21 | <AryehGregor> | Okay, so it turns out that no one but IE even pretends to implement IDLs from (for instance) DOM4 per spec. |
| 16:21 | <AryehGregor> | The prototypes don't have the expected properties at all. |
| 16:22 | <AryehGregor> | Like, say, Node.prototype.nodeType is just undefined except in IE. |
| 16:22 | <AryehGregor> | IE9 implements spec almost perfectly. |
| 16:23 | <karlcow> | annevk: not sure. An author in France can't put his work in the public domain. It doesn't exist. The work will be upgraded to public domain 70 years after the death of the author, but he can't do it before. (which is stupid we agree.) |
| 16:23 | <AryehGregor> | In Gecko, it looks like all the properties are just dumped on the thing lowest on the prototype chain. Like nodeType is in Text.prototype and Element.prototype, but not Node.prototype. |
| 16:24 | <annevk> | karlcow: yes but CC0 is a copyright |
| 16:25 | <annevk> | karlcow: copyright license |
| 16:25 | <karlcow> | hmm indeed. The name is confusing. |
| 16:26 | <AryehGregor> | In WebKit, it looks like document has a property nodeType which is neither an own property nor anywhere in the prototype chain. |
| 16:26 | <AryehGregor> | Which is HTMLDocument -> Document -> Node -> Object as expected. |
| 16:27 | <AryehGregor> | -> null. |
| 16:29 | <AryehGregor> | Opera seems similar. |
| 16:29 | <AryehGregor> | Gecko has the property on the prototype too, but not as an own property. |
| 16:29 | AryehGregor | shakes head in disbelief |
| 16:29 | <AryehGregor> | I guess we just get lots of tests that only IE passes, huh? |
| 16:30 | <AryehGregor> | Well, it depends on the interface. Selection is more sane in Gecko, for instance. |
| 16:30 | AryehGregor | goes back to adding features to his tests |
| 16:33 | tantek | rejoins from Redmond. |
| 16:48 | tantek | reads https://plus.google.com/107429617152575897589/posts/3ZEQAVkF6xd to catch up on the fun. |
| 16:52 | <dglazkov> | good morning, Whatwg! |
| 16:53 | <Rik`> | http://blogs.computerworlduk.com/open-enterprise/2011/11/mozillas-brendan-eich-on-the-birth-of-firefox/index.htm |
| 16:53 | <Rik`> | wow, I never knew hyatt was at Apple when working on Phoenix |
| 16:59 | tantek | realizes he should have asked for a time extension for the revert request regarding time/data during last week's HTML WG teleconference. :/ |
| 17:06 | <annevk> | tantek: yeah well |
| 17:06 | <annevk> | tantek: it'll be sorted out in due course |
| 17:07 | tantek | is still a bit slow on all the W3C process stuff. |
| 17:07 | <tantek> | yeah, but with unfortunate wasted time on the part of Mike Smith and Hixie. |
| 17:07 | <annevk> | most WGs don't have this |
| 17:07 | tantek | really hates source control gymnastics and thus sympathizes greatly with both of them. |
| 17:08 | <AryehGregor> | jgraham, do you propose any way of parsing IDLs from JS other than lots of messy regex? |
| 17:08 | <AryehGregor> | Because that's pretty much working for me so far, but it doesn't seem super ideal. |
| 17:12 | <jgraham> | AryehGregor: Write or steal a proper parser? |
| 17:12 | <AryehGregor> | jgraham, such as from where? |
| 17:12 | <jgraham> | Well one exists but it depends on peg.js and I don't know how that plays with licenses |
| 17:12 | <AryehGregor> | Will it parse WebIDL's format, anyway? |
| 17:12 | <jgraham> | (google for WebIDL parser javascript) |
| 17:12 | <AryehGregor> | Oh, there are WebIDL-specific ones, nice. |
| 17:12 | <AryehGregor> | I've already got a mostly-working regex one, but it's slightly horrifying. |
| 17:13 | <AryehGregor> | Or more than slightly. |
| 17:13 | <AryehGregor> | Perhaps extremely. |
| 17:13 | <AryehGregor> | You are probably not surprised at my approach to the problem. |
| 17:13 | <jgraham> | The alternative is just to write one. Which could be fun but has a cost. |
| 17:15 | <jgraham> | (it seems like the licensing terms are rather OK) |
| 17:16 | <smaug____> | annevk: CORS has been supported quite a long time |
| 17:16 | <jgraham> | I would suggest that whatever we do we put all of this into a different script that one must include in addition to testharness[report].js |
| 17:16 | <smaug____> | annevk: so preventing sync might break some sites |
| 17:17 | <smaug____> | (I wouldn't be surprised it for example Google Docs would break) |
| 17:17 | <smaug____> | s/it/if/ |
| 17:22 | <AryehGregor> | jgraham, why? |
| 17:24 | <jgraham> | AryehGregor: Because it is a significant amount of extra script that isn't needed (and doesn't have to be understood) for most tests |
| 17:24 | <AryehGregor> | Okay, doesn't matter to me. |
| 17:25 | <jgraham> | A typical API will need one file that does generate_idl_tests(IDL) |
| 17:25 | <AryehGregor> | I was thinking a better API would be to expose an extra type of object that can generate various sorts of tests from the IDL. |
| 17:25 | <AryehGregor> | So you might want to test that a specific object is an instance of an interface, for instance. |
| 17:25 | <jgraham> | Maybe |
| 17:26 | <jgraham> | In any case having that all in a single file per API seems reasonable |
| 17:26 | <jgraham> | and not having the extra code in other tests for the same API also seems reasonable |
| 17:31 | <AryehGregor> | Okay, so it looks like the first interface I tried testing in the WebIDL parser is actually an invalid WebIDL interface to start with. |
| 17:31 | <AryehGregor> | It has an enum, which apparently doesn't exist in WebIDL. |
| 17:31 | <AryehGregor> | Good error to catch. |
| 17:32 | <AryehGregor> | (this is Range per DOM4) |
| 17:33 | <AryehGregor> | Seems to work nicely. |
| 18:24 | <AryehGregor> | jgraham, okay, so my proposed syntax is now new IdlInterface('interface .....').test(); to test. |
| 18:24 | <AryehGregor> | That runs tests based on the interface object itself. |
| 18:24 | <AryehGregor> | Then later we can add methods that test other things, like test that something is an instance of the interface. |
| 18:24 | <AryehGregor> | Sound good? |
| 18:25 | <AryehGregor> | The code is in its own file that has to be included separately. |
| 18:27 | <AryehGregor> | I'll commit the WebIDL parser too, which says it's under the MIT license, which I assume is fine. |
| 18:30 | <annevk> | you have a proper WebIDL parser? |
| 18:30 | <annevk> | cool |
| 18:30 | <AryehGregor> | annevk, https://github.com/darobin/webidl.js/tree/ |
| 18:30 | <AryehGregor> | It seems to work for all the correct IDLs I've tried so far. |
| 18:30 | <AryehGregor> | The Range IDL in DOM4 is wrong, I think, it uses a construct (enum) not defined by WebIDL. |
| 18:31 | <annevk> | yeah, DOM might soon use some other non-standard constructs |
| 18:31 | <annevk> | union! |
| 18:31 | <zewt> | D: |
| 18:31 | <AryehGregor> | :( |
| 18:32 | <AryehGregor> | Define them in WebIDL plz? |
| 18:32 | <AryehGregor> | . . . also, what would a union be in JS? |
| 18:32 | <annevk> | union is mostly for vararg overloading |
| 18:33 | <annevk> | and I suspect heycam will add it in due course |
| 18:33 | <annevk> | but can't have all new features wait for Web IDL improvements |
| 18:34 | <zewt> | union sort of implies overlapping memory, though, which doesn't make sense in JS of course |
| 18:37 | <AryehGregor> | http://dvcs.w3.org/hg/html/file/ecdfd06cbdc9/tests/resources/idlharness.js |
| 18:49 | <zcorpan> | AryehGregor: seriously cool |
| 18:50 | <zcorpan> | AryehGregor: it might be annoying that you have to use one string per interface |
| 18:50 | <AryehGregor> | As opposed to just one giant string that you run all the tests on? |
| 18:50 | <AryehGregor> | That should be relatively easy to change. |
| 18:51 | <zcorpan> | yeah |
| 18:51 | <AryehGregor> | http://aryeh.name/tmp/webapps/DOMCore/tests/submissions/AryehGregor/interfaces.html |
| 18:51 | <AryehGregor> | The thing is, I want to add other methods like IdlInterface.prototype.test_instance() that tests something is an instance of the interface, say. |
| 18:52 | <AryehGregor> | Although maybe a better strategy would be to concatenate all the IDLs from all the specs and have one giant IDL object that represents everything about all standard IDLs. |
| 18:52 | <AryehGregor> | That would give the most flexibility for testing. |
| 18:52 | <AryehGregor> | But this is a good start, I think. |
| 18:53 | <zcorpan> | i dunno, but i imagined that it would be nice to use the interfaces in a <script> data block instead of using \n\ |
| 18:53 | <AryehGregor> | That would be less ugly, certainly. |
| 18:53 | <zcorpan> | i agree it should be possible to test instances |
| 18:54 | <AryehGregor> | http://w3c-test.org/webapps/DOMCore/tests/submissions/AryehGregor/interfaces.html |
| 18:55 | <zcorpan> | maybe testing instance could be a bit different. like you parse all interfaces first, then call a method like testInstance(instance, 'HTMLVideoElement') or something |
| 18:57 | <AryehGregor> | Potentially, yeah. |
| 18:58 | <AryehGregor> | Improvements welcome. |
| 18:59 | <AryehGregor> | For now, I have to get back to actual Selection/Range stuff . . . this has been a bit of a detour. |
| 18:59 | <zcorpan> | really nice work |
| 19:03 | <AryehGregor> | There's loads more to do. |
| 19:03 | <AryehGregor> | WebIDL has tons of requirements that could be tested. |
| 19:05 | <zcorpan> | i've wanted to write this sort of thing myself, so i might just jump in |
| 19:06 | <AryehGregor> | :) |
| 19:09 | <wilhelm_> | Very nice indeed. |
| 19:19 | <roc> | AryehGregor, jgraham: David Flanagan's dom.js project has a WebIDL parser in JS |
| 19:19 | <tantek> | hey brucel - you had questions about <time> |
| 19:19 | <AryehGregor> | roc, interesting. I found a (presumably) different one that seems to work well enough. |
| 19:20 | <jgraham> | AryehGregor: Cool. |
| 19:20 | <jgraham> | AryehGregor: I don't want to have one giant IDL block though |
| 19:21 | <AryehGregor> | jgraham, that would be what's easiest if we use <script> for data. |
| 19:21 | <jgraham> | You should be able to copy from the spec, paste it into a test file and get useful tests |
| 19:21 | <AryehGregor> | Which would be nicer. |
| 19:21 | <AryehGregor> | Yes, but there are some tests that you can't do easily unless the test knows about all the different IDLs. |
| 19:21 | <jgraham> | Such as? |
| 19:21 | <AryehGregor> | Like if one interface has a member whose type is another interface. |
| 19:21 | <AryehGregor> | I guess you don't need to do all the checks on that, though. |
| 19:22 | <AryehGregor> | Just instanceof would probably be fine. |
| 19:22 | <jgraham> | Yeah |
| 19:22 | <AryehGregor> | Which doesn't need the IDL for the other interface. |
| 19:22 | <jgraham> | Indeed |
| 19:22 | <jgraham> | the other interface can be tested seperatly |
| 19:24 | <jgraham> | Also, as gsnedders said, there is probably a great deal one can do if one has an API that takes an IDL block and a function returning an object that should implement that IDL block |
| 19:24 | <roc> | I don't think hsivonen and glazou disagree all that much. Everyone agrees that if browsers never shipped prefixed/non-CR stuff in release builds, we wouldn't have a problem |
| 19:25 | <AryehGregor> | jgraham, I was thinking that would be a separate method on IdlInterface. |
| 19:25 | <jgraham> | roc: That seems like a pointless thing to agree on since it won't ever happen (people not shipping in release until CR) |
| 19:25 | <AryehGregor> | Yay, I wrote a test that passes in Firefox if I run it in Firebug but fails if I run it without Firebug. |
| 19:25 | <roc> | yeah, the major point of difference is that glazou thinks that's possible |
| 19:25 | <zcorpan> | instanceof won't work if the interface is [NoInterfaceObject] |
| 19:26 | <jgraham> | roc: And therein lies the problem. Glazou seems to have a broken idea of the market dynamics |
| 19:26 | <AryehGregor> | zcorpan, hmm, true. |
| 19:26 | <jgraham> | zcorpan: True, but that's a bit of an edge case |
| 19:26 | <tantek> | woo - ratholing on prefixes again? |
| 19:26 | <tantek> | anyone want to talk <time> element instead? ;) |
| 19:27 | <zcorpan> | <time> to go! |
| 19:33 | <hsivonen> | roc: I'm not expecting stuff to stay in experimental builds until CR under the current CSS WG notion of CR |
| 19:33 | <roc> | I'm not either |
| 19:34 | <hsivonen> | roc: I expect stuff to go to release when the pressure to ship outweighs doubts about the design of the feature |
| 19:34 | <smaug____> | not removing prefixes causes also some problems. That indicates to authors that they can rely on feature, although the feature should be just experimental |
| 19:34 | smaug____ | doesn't quite understand why webkit doesn't remove prefixes |
| 19:35 | <hsivonen> | smaug____: shipped features aren't really experimental |
| 19:35 | <smaug____> | they can be |
| 19:35 | <smaug____> | if it is clear to everyone that prefixed things can go away at any point |
| 19:35 | <jgraham> | The problem with the notion of "experimental" builds is that typically the features aren't used by enough users to get really good feedback |
| 19:35 | <hsivonen> | smaug____: the authors decide what they treat as experimental when stuff is in release builds |
| 19:35 | <smaug____> | but apparently that isn't happening, at least in some browser engines |
| 19:36 | <jgraham> | (I'm excluding nightly/dev track builds where features are on by default and expected to transition into the next release) |
| 19:36 | <hsivonen> | smaug____: WGs or vendors don't get to make authors treat stuff as experimental after shipping |
| 19:37 | <jgraham> | Well I say "the" problem; I mean "one of the problems" |
| 19:37 | <smaug____> | hsivonen: well, part of that problem is that prefixes aren't being removed actively |
| 19:38 | <hsivonen> | smaug____: I wouldn't be too surprised if the bar for removing a -webkit-prefixed feature was around the bar for removing a Cocoa API call from Mac OS X |
| 19:38 | <hsivonen> | smaug____: dunno what their actual policy is |
| 19:39 | <hsivonen> | (I'd appreciate a pointer to their policy if there is one) |
| 19:40 | <jgraham> | AryehGregor: So, it would be nice if we could structure the code in some more straightforward way. I'm not sure quite what that is, but given an attribute x on a property y, it would be nice if all the tests for (x,y) were localised in a given place |
| 19:40 | <AryehGregor> | jgraham, what do you mean? |
| 19:43 | <roc> | hsivonen: I started a thread on www-style about removing prefixes from some CSS properties, you may wish to contribute |
| 19:45 | <Hixie> | hsivonen: i am offended by your characterisation of replacing <time> with <data> as a "stunt" |
| 19:53 | <AryehGregor> | jgraham, to test that an object implements an interface, you also want to test that it implements all the interfaces that one inherits. If we don't have a single object that knows about lots of IDLs, this means you'll have to do something like test_implements(document, "HTMLDocument"); test_implements(document, "Document"); test_implements(document, "Node"); which a) is error-prone, b) doesn't test that the inheritance is in the correct orde |
| 19:53 | <AryehGregor> | r. |
| 19:54 | <AryehGregor> | (although I don't know if (b) is actually meaningful) |
| 19:54 | <hsivonen> | roc: I already posted one contribution to the thread |
| 19:55 | <roc> | ok |
| 19:55 | <hsivonen> | Hixie: I'm sorry about my bad choice of words. I think the removal of <time> in that manner was bad PR for the Living Standard model and for HTML5 |
| 19:56 | <Hixie> | yes |
| 19:56 | <Hixie> | clearly :-) |
| 19:57 | <Hixie> | but these things will happen |
| 20:17 | <Hixie> | if anyone is interested in <time>'s duration syntax, it would be really helpful if you could fill out http://www.whatwg.org/specs/web-apps/current-work/temp and mail me your results |
| 20:17 | <Hixie> | also feel free to add any other cases you think are important |
| 20:18 | <Hixie> | tantek: it would be really helpful if you could fill out http://www.whatwg.org/specs/web-apps/current-work/temp and mail me your results (feel free to add any other cases you think are important) |
| 20:18 | <dglazkov> | is there a spec for the Living Standard Model? |
| 20:18 | <Hixie> | dglazkov: "put the spec on the web and keep it updated" |
| 20:19 | <dglazkov> | :) |
| 20:19 | <Hixie> | bbiab |
| 20:28 | <tantek_> | Hixie, I do think we can improve on ISO8601's duration syntax |
| 20:28 | <tantek_> | what I wrote up on the Time wiki page was my first thoughts |
| 20:29 | <AryehGregor> | What's an example of a real-world interface that has two operations with the same name? Anything? |
| 20:29 | <AryehGregor> | DOM4 doesn't have any. |
| 20:29 | <Ms2ger> | Canvas? |
| 20:32 | <AryehGregor> | createPattern, okay. |
| 20:34 | <Ms2ger> | > "CSS3 browser" and "CSS4 browser" are meaningless terms. |
| 20:34 | <Ms2ger> | No, they are not. If that were the case, there is no point in having Level 4 vs. Level 3 modules. |
| 20:34 | <Ms2ger> | Who's going to tell Brian there's no point? |
| 20:35 | <jamesr_> | there's a point to having level 3 vs level 4 modules? |
| 20:35 | <jamesr_> | news to me |
| 20:37 | <tantek_> | different level modules yes. making claims of a "CSS3 Browser" or "CSS4 Browser" no. |
| 20:38 | <roc> | I agree with tantek |
| 20:39 | <roc> | well, somewhat. I'm not sure if labeling modules with revision levels is a good idea, but it doesn't matter here |
| 20:41 | <tantek> | roc, the way I see the revision levels is basically for snapshotting sets of "stable" feature |
| 20:41 | <tantek> | features |
| 20:41 | <tantek> | per module |
| 20:41 | <roc> | yes |
| 20:42 | <tantek> | to translate with the "living spec" terminology - |
| 20:42 | <roc> | but it's a heavyweight process which requires us to make editorial decisions, sometimes controversial ones, to allow stable features to progress independent of unstable features |
| 20:42 | <roc> | we could fix that by putting every feature in its own module, but that would create new problems |
| 20:43 | <roc> | or, we could simply fix it by allowing features within the same module to be independently marked stable, at least for unprefixing purposes |
| 20:43 | <roc> | which is what I'm proposing |
| 20:43 | <tantek> | module X level N is the live version until it enters CR at which point it becomes a feature freeze fork (where some features may be dropped), and module x level N+1 becomes the live version |
| 20:44 | <tantek> | yeah, at what point during CR do prefixes get dropped is an interesting question |
| 20:44 | <tantek> | I've heard a variety of different opinions |
| 20:44 | <tantek> | though there is some convergence on CR + test suite for a feature/property/value + prefixed 2 implementations that behave the same way = ok to unprefix that feature/property/value |
| 20:45 | <tantek> | and yes that would mean features/properties/values within the same specification being marked independently "stable" for the purpose of removing vendor prefixes |
| 20:46 | <tantek> | those 3 conditions (CR, tests, 2+ interoperable prefixed implementations) are from experience in the CSS WG |
| 20:46 | <tantek> | though one could make a case that the CR portion of that is a "nice to have" |
| 20:46 | <Ms2ger> | Would be great to have tests, of course |
| 20:47 | <tantek> | Ms2ger - I think it is irresponsible to remove prefixes from a feature without tests for the feature. |
| 20:47 | <astearns> | can't assess "interoperable" without tests |
| 20:47 | <jamesr_> | in practice css module revision #s seem mostly like a way to punt on proposals by saying "we'll think about that in revision N+1" |
| 20:47 | <tantek> | astearns, bingo |
| 20:47 | <Ms2ger> | tantek, in the implementation's or the standard's test suite? |
| 20:48 | <tantek> | Ms2ger the latter - with tests that use the prefixed version(s) |
| 20:48 | <Ms2ger> | All for, glwt |
| 20:48 | <tantek> | jamesr_ I hear your frustration. |
| 20:51 | <roc> | jamesr_: that's a good thing |
| 20:51 | <roc> | well, it's good to be able to stop people adding stuff that prevents the spec from progressing |
| 20:51 | <roc> | it's not good to have new features gated on the progress of unrelated features |
| 20:52 | <tantek> | jamesr_ also - for any specific CSS proposal, there's always a way for folks to incrementally develop them, on the www-style list, on wiki.csswg.org etc. |
| 20:52 | <roc> | but you can never reach unprefixed status that way |
| 20:52 | <tantek> | and that way, as roc points out, such ideas can be iterated without blocking more mature features. |
| 20:54 | <roc> | astearns: authors assess "interoperable" when they routinely pass the same values to all browsers' prefixed properties |
| 20:54 | <roc> | when that's happening, it's interoperable enough |
| 20:54 | <astearns> | that's determined by their own testing for when they can do that reliably |
| 20:55 | <astearns> | for what ever value of "reliably" works for them |
| 20:55 | <jamesr_> | roc, i think it's a good thing to punt |
| 20:55 | <jamesr_> | so long as there are good reasons |
| 20:57 | <roc> | astearns: yeah, that's what "interoperable enough" means |
| 20:58 | <astearns> | so it's not a complete test suite that's needed. Just enough to check what authors mean for "interoperable" |
| 20:58 | <tantek> | astearns, anyone can submit test cases for CSS features. |
| 20:59 | <tantek> | so for any author complaining about prefixes, I say, submit what test cases you think demonstrate interop between prefixed implementations. |
| 20:59 | <Ms2ger> | Ah, and who does? |
| 20:59 | <Ms2ger> | Apart from Gérard |
| 20:59 | <roc> | realistically, they're not going to submit testcases |
| 21:00 | <astearns> | I'm encouraging the teams at Adobe who code around browser incompatibilities to submit tests :) |
| 21:00 | <roc> | making this whole process depend on authors doing work is doomed |
| 21:00 | <tantek> | roc, it makes sense to put burden on the complainers |
| 21:00 | <tantek> | as a logical extension of the OSS "patches welcome" philosophy |
| 21:02 | <zewt> | ... it hardly seems appropriate to label people who want interoperable APIs as "complainers" |
| 21:02 | <roc> | if we could aggregate and harness the negative energy of millions of Web developers for useful purposes, we could be as gods |
| 21:02 | <zewt> | heh |
| 21:04 | <TabAtkins> | roc: I believe that prefixes are, in general, a good thing, but that prefixes, in several particular instances we're struggling with, have been a bad thing due to the specs languishing in a pre-CR state. |
| 21:04 | <roc> | I'm undecided on the former, but we can fix the latter independent of that |
| 21:05 | <TabAtkins> | Yes, we can. |
| 21:05 | <zewt> | TabAtkins: for CSS prefixes specifically, or scripting prefixes as well? |
| 21:05 | <TabAtkins> | And we can also limit the pain that such languishing causes in the future, and maybe even produce a dynamic that makes languishing explicitly antisocial. |
| 21:05 | <TabAtkins> | By, for example, limiting prefixed properties to beta or earlier only. |
| 21:05 | <zewt> | people tend to say "prefixes" when they're thinking more of one or the other, i think |
| 21:05 | <TabAtkins> | zewt: Both, in my opinion. |
| 21:06 | <roc> | I would love to have a world where prefixed properties aren't in release builds |
| 21:06 | <TabAtkins> | roc: We've seriously considered it. |
| 21:06 | <TabAtkins> | roc: We need to make a pact. |
| 21:06 | <zewt> | it's not clear to me, since the entire "living standard" concept essentially discards the notion of arriving at CR |
| 21:07 | <tantek> | TabAtkins - the game theory of the situation won't allow that to happen: "a world where prefixed properties aren't in release builds" |
| 21:07 | <TabAtkins> | zewt: That's not true. Push the CSSWG just a *little* bit farther, and you ahve a living stadnard within the confines of W3C process. |
| 21:07 | <tantek> | good luck on eliminating -webkit- properties from release Safari builds |
| 21:07 | <TabAtkins> | tantek: Eliminating the current ones, of course not. |
| 21:07 | <TabAtkins> | But keeping new ones from trickling down is doable. |
| 21:07 | <zewt> | TabAtkins: i'm more familiar with the scripting side of things than CSS |
| 21:07 | <tantek> | zewt see above my translation of module levels to living spec |
| 21:08 | <tantek> | Tabatkins, I agree, CSSWG is approaching living spec-like working routines |
| 21:08 | <tantek> | I think we can get there |
| 21:08 | <TabAtkins> | Doing a proper living standard within the process just requires small modules and active pushing to CR. |
| 21:08 | <tantek> | TabAtkins - I think it requires more than that, but those are good steps |
| 21:09 | <zewt> | a simple case i'm thinking of is eg. webkitURL.createObjectURL, and wondering when that should be unprefixed, since even after that API is fairly stable and interoperably implemented (and it probably is, at this point), new methods will presumably be added to URL in the future |
| 21:09 | <tantek> | e.g. when module X level N goes to CR, issuing a public WD of module X level N+1 |
| 21:09 | <zewt> | in that particular case, i suppose it makes more sense to prefix the methods, instead of URL itself |
| 21:09 | <tantek> | right |
| 21:09 | <TabAtkins> | zewt: Yes, once the core object is "stable", you prefix methods. |
| 21:09 | <tantek> | it's case by case |
| 21:09 | <tantek> | even in CSS |
| 21:09 | <tantek> | sometimes we prefix properties |
| 21:09 | <zewt> | (URL.webkitCreateObjectURL instead of webkitURL.createObjectURL) |
| 21:09 | <tantek> | other times, values |
| 21:09 | <TabAtkins> | Just like how, in CSS, you start by prefixing the property, and later prefix the values. |
| 21:10 | <tantek> | lol, take it away TabAtkins :) |
| 21:10 | <TabAtkins> | Hehe. ^_^ |
| 21:11 | <zewt> | (of course, prefixing loses a lot of its meaning unless everyone does it, and firefox doesn't prefix URL, heh--though it doesn't lose *all* meaning) |
| 21:13 | <Phrogz_> | http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#origin has three specs relating to data: urls on images. The last two confuse me. What does the word "found" mean in the context of "found in another Document or script"? |
| 21:13 | <Phrogz_> | I suspect that it is the last spec that is preventing this page: http://phrogz.net/SVG/svg_to_png.xhtml from working as intended. Chrome is throwing a security error trying to round trip an SVG image from the same document through a canvas. |
| 21:15 | <TabAtkins> | No, that's not it. We just specifically taint canvases when you draw any SVG into them. |
| 21:15 | <Phrogz_> | TabAtkins: Oh? Can't tell if you're joking or not. If not...why on earth? |
| 21:15 | <TabAtkins> | Not joking. It's because the security issues are complicated, and we're punting for now. |
| 21:16 | <TabAtkins> | Dealing with <foreignContent> requires some subtlety. |
| 21:16 | <Phrogz_> | OK. May I ask who "we" are? (For a StackOverflow answer I'd like to cite my source. :) |
| 21:16 | <TabAtkins> | Chrome engineer. |
| 21:16 | <Phrogz_> | Thanks. Any mailing list discussion on this topic you could point me at (or in the general vicinity of)? |
| 21:17 | <TabAtkins> | I'd have to dig stuff up. Search in public-webapps⊙wo for posts from Adam Barth about it? |
| 21:18 | <Phrogz_> | Thanks. Any keywords you'd recommend? Taint? origin-clean? svg? foreignObject? |
| 21:18 | <hober> | drawElement |
| 21:18 | <zewt> | heh, i got bored of stackoverflow ... too little filtering for quality of questions leading to too many crap questions to wade through |
| 21:19 | <Phrogz_> | zewt: That's the truth for sure. Still, there's a glimmer of hope there for storing good answers. Plus, I'm foolishly addicted to the rep. Jeff's got his claws in me. |
| 21:19 | <zewt> | pages of people looking to get their homework done gets tiresome |
| 21:21 | <Phrogz_> | So, that explains my specific question. Still, I'm interested in the difference between those last two image/data: url specs. Can anyone clarify? |
| 21:21 | <gavinc> | zewt: Perhaps might be faster to change how homework is assigned rather then trying to get people to stop looking for answers online. The first only seems really hard, the 2nd impossible. |
| 21:22 | <annevk> | Hixie: using datetime as attribute seems annoying |
| 21:22 | <annevk> | AryehGregor: XMLHttpRequest.send() |
| 21:23 | <TabAtkins> | Phrogz_: I think the "other Document" that's referring to just means "other than the image referred to by the data: url" |
| 21:25 | <Phrogz_> | TabAtkins: ? I suppose it would be clearer to me if someone could give an example of when the first case might occur. (What javascript code would result in an image having a data URL that was "found" in another Document or script?) |
| 21:25 | <annevk> | roc: I'm happy to have Opera drop the prefixes for the modules you proposed btw |
| 21:25 | <annevk> | roc: for those we implement anyway :) |
| 21:25 | <roc> | please say so on the list |
| 21:26 | <roc> | and mention whether you'd be happy for other browsers to drop prefixes on the features you don't implement :-) |
| 21:26 | <zewt> | Phrogz_: iframes? (but if the iframe isn't same-origin then you can't access the IMG in question in the first place) |
| 21:28 | <TabAtkins> | Phrogz_: For example, if you use an <iframe> whose document contains a data: url. |
| 21:28 | <TabAtkins> | Phrogz_: I think that's the right interpretation. |
| 21:33 | <annevk> | roc: done and done |
| 21:35 | <annevk> | AryehGregor: IDL interface tests, sweet |
| 21:35 | <annevk> | AryehGregor: you're on a roll :) |
| 21:36 | <jgraham> | TabAtkins: Who has discussed not shipping prefixed stuff in stable builds? It seems unlikely that such a policy would meet with universal approval at google since afaik your products use -webkit-* for stuff that others don't have yet |
| 21:37 | <tantek> | jgraham - agreed. |
| 21:37 | <Ms2ger> | AryehGregor, did you look at the ProgressEvent tests, btw? |
| 21:37 | <jgraham> | (by "products" I mean "websites") |
| 21:38 | <Ms2ger> | text/html XHR was backed out, btw |
| 21:38 | <jgraham> | AryehGregor: I mean I want the code to be structured more clearly than a big series of "if" statements, such that it is easy to find all the tests relating to a particular attribute in the IDL |
| 21:38 | <annevk> | Ms2ger: something broke? |
| 21:38 | <jgraham> | Or other part of the IDL |
| 21:39 | <Ms2ger> | Tests |
| 21:40 | <annevk> | tests |
| 21:40 | <annevk> | the ultimate troll |
| 21:41 | <jamesr_> | we've (chromium) thought having things that are on in dev builds but not beta / stable |
| 21:41 | <jamesr_> | it gets tricky though |
| 21:41 | <jgraham> | tantek: Producing a *good* testsuite for a spec is often lots of work. Perhaps more than implementing it. Almost no spec currently has a good testsuite (CSS 2.1 has a patchy but reasonable testsuite and that took *years*). Gating unprefixing on testsuites either requires a big change in how we get tests (suggestions welcome!) or just perpetuates the current problem |
| 21:41 | <jamesr_> | for example you lose some of the benefits of having a dev channel if the thing you release to beta is not what was previously on dev |
| 21:42 | <jgraham> | In practice authors are often happy to work around bugs in a feature if they get to use that feature |
| 21:42 | <jamesr_> | some of the QA/testing benefits that is |
| 21:44 | <roc> | another option is to ship prefixed features in all builds, but disabled behind a preference/config flag |
| 21:44 | <annevk> | heh, private flame from glazou |
| 21:44 | <annevk> | roc: then you might as well do it unprefixed behind a config flag |
| 21:45 | <roc> | that works too |
| 21:45 | <roc> | then anyone can try the feature, we don't have to worry about code differences between dev and release builds, and authors still can't rely on it |
| 21:45 | <tantek> | jgraham - note that I specifically said test cases/suite for a *feature/property/value* - not a *spec* |
| 21:45 | <tantek> | very different problem |
| 21:46 | <annevk> | it seems though that we should be able to nail down a feature within half a year or so |
| 21:46 | <dglazkov> | I want to print this out and frame it: "They care whether two UAs have incompatible implementations, because it affects their work. They don't care what the exact reasons are _why_ that happens. -- Zbarsky." |
| 21:46 | <tantek> | so yeah, please no strawmen |
| 21:46 | <annevk> | and within half a year we have happily made changes thus far |
| 21:46 | <annevk> | for non-CSS features |
| 21:46 | <annevk> | so I really think it's a non-issue |
| 21:46 | <jgraham> | tantek: Depends on the feature |
| 21:46 | <annevk> | CSS just need to get with the times |
| 21:46 | <tantek> | jgraham - sure |
| 21:46 | <jgraham> | tantek: There still isn't a really good <video> testsuite afaik |
| 21:47 | <jgraham> | And yt everyone ships and no one says it should be prefixed |
| 21:47 | <jgraham> | (prefixing is harder in HTML ofc. This doesn't seem o turn out bad very often) |
| 21:47 | <divya> | i like roc's suggestion of a config flag |
| 21:47 | <tantek> | jgraham - because both Opera and Mozilla made changes to <video> as necessary in implementations |
| 21:47 | <tantek> | rather than be saddled with compat modes for old <video> content |
| 21:47 | <tantek> | but not all implementations work that way |
| 21:48 | <jgraham> | I don't understand your point |
| 21:48 | <jgraham> | In HTML and mostly in the APIs we haven't had prefixes |
| 21:48 | <tantek> | jgraham - OTOH CSS 'clip' property failed because it was implemented unprefixed, incompatibly, in IE which then had compat reasons that prevented fixing it. |
| 21:49 | <jgraham> | What are the cases that turned out really bad that prefixing would have fixed |
| 21:49 | <annevk> | 'filter' maybe, though it might turn out alright in the end |
| 21:49 | <tantek> | so yes, unprefixed implementation by vendors who don't mind breaking early content have worked |
| 21:49 | <annevk> | there's like a few examples |
| 21:49 | <jgraham> | tantek: Incompatibly with what? |
| 21:49 | <tantek> | but that's only a few |
| 21:49 | <zewt> | blob.slice was tricky to fix, iirc |
| 21:49 | <annevk> | but they by far do not outweigh gradients, transitions, etc. |
| 21:49 | <tantek> | spec, other implementations etc. edge cases etc. |
| 21:49 | <tantek> | clip was *very* problematic |
| 21:49 | <annevk> | you mean the space-separated stuff? |
| 21:50 | <tantek> | that was the beginning of the reasons for doing prefixes |
| 21:50 | <jgraham> | local storage could have ended up better, but prefixing wouldn't have helped (probably) |
| 21:50 | <Phrogz_> | TabAtkins: So you think that img.src = frames[1].document.querySelector('#hasdataurl').src; would trigger the first case, but img.src = frames[1].document.querySelector('#hasdataurl').src.replace('1','3') would trigger the second origin policy? |
| 21:50 | <tantek> | jgraham, prefixing the DOM APIs for localStorage could have fixed it as well |
| 21:50 | <Phrogz_> | (Where 'first' is the next-to-last and 'second' is the last spec under image origin. Wish each of these had specific identifiers.) |
| 21:50 | <annevk> | remember, we had globalStorage first |
| 21:51 | <jgraham> | tantek: With clip, others shipped first and Microsoft just released a buggy implementation? Or Microsoft shipped first? |
| 21:51 | <annevk> | it took a very long time for localStorage problems to crop up |
| 21:51 | <annevk> | too long basically |
| 21:51 | <jgraham> | Right, prefixing wouldn't have helped |
| 21:51 | <jgraham> | Because the problems didn't become clear for so long that any sane process would have unprefixed |
| 21:51 | <jgraham> | Or flash would have won |
| 21:52 | <zewt> | it's not clear that localStorage's basic API is even fixable, since most of the likely fixes end up killing its main appeal (convenience) |
| 21:54 | <roc> | should I bother restarting the thread with the language Brian wants? |
| 21:55 | <tantek> | roc, URL? |
| 21:56 | <zewt> | webkitURL |
| 21:56 | <TabAtkins> | Phrogz_: I'm not sure. :/ |
| 21:57 | <TabAtkins> | jgraham: Us in WebKit. It would indeed be unpopular with our Apps teams. That doesn't mean we couldn't do it. |
| 21:58 | <Phrogz_> | TabAtkins: OK, thanks. I'll try bringing this to the mailing list. |
| 21:58 | <tantek> | TabAtkins, to start with, dropping prefixed versions of properties when you implemented the unprefixed version would be a good start. Mozilla has that policy. |
| 21:58 | <TabAtkins> | tantek: I know they do. That's very likely not going to happen. |
| 21:58 | <tantek> | TabAtkins, why? |
| 21:58 | <tantek> | seems easier / less tempting than not adding them in the first place. |
| 21:59 | <TabAtkins> | For one thing, those properties are often used in *Apple* products that can't easily be updated. For two, preventing our Apps teams from using new stuff as quickly is one thing, making them remove stuff they already have is another. ^_^ |
| 21:59 | <TabAtkins> | tantek: And no, it's much harder than not adding int he first place. |
| 21:59 | <tantek> | commenting out code so much easier than writing it :p |
| 22:00 | <Phrogz_> | Is public-webapps⊙wo the right spot to discuss http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#origin-0 ? |
| 22:00 | <TabAtkins> | Better to email whatwg⊙wo |
| 22:01 | <TabAtkins> | The fact that public-webapps shares a naming similarity with part of the URL for the html spec is a coincidence. |
| 22:01 | <Phrogz_> | kk |
| 22:01 | <Ms2ger> | Well, not a coincidence... Both are about web apps |
| 22:01 | <TabAtkins> | Well, yeah. But WebApps doesn't do the HTML spec. |
| 22:02 | <hober> | TabAtkins: happy birthday! |
| 22:02 | <TabAtkins> | hober: Thanks! |
| 22:02 | <Ms2ger> | And that |
| 22:05 | <dglazkov> | TabAtkins: Happy birthday! |
| 22:06 | <roc> | Wait, it's Tab's birthday? |
| 22:06 | <roc> | Mine too! |
| 22:06 | <TabAtkins> | Yay! |
| 22:06 | <TabAtkins> | Birthday buddies! |
| 22:06 | <roc> | except I'm about 50 years old |
| 22:06 | <roc> | er |
| 22:07 | <Ms2ger> | Congratulations/Condolences then |
| 22:08 | <jgraham> | Aren't you also on different sides of midnight? |
| 22:08 | <TabAtkins> | Oh, yeah, I guess. |
| 22:08 | <TabAtkins> | roc: You're Nov 17? |
| 22:09 | <roc> | oooh yeah |
| 22:09 | <roc> | yes, I live in the future |
| 22:09 | <annevk> | heh |
| 22:09 | <jgraham> | Happy birthday both (although seeing "happy birthday" always makes me start humming "unhappy birthday" by The Smiths, so that too) |
| 22:09 | <annevk> | happy birthday to both of you! |
| 22:10 | <TabAtkins> | Not birthday buddies, then. |
| 22:10 | <TabAtkins> | ;_; |
| 22:10 | <dglazkov> | jgraham: you are truly a grump :) |
| 22:11 | <jgraham> | No, no, it is just that the smiths are very hummable |
| 22:11 | <jgraham> | Well also yes |
| 22:12 | <jgraham> | But mostly the humming thing in this case |
| 22:12 | <dglazkov> | ah. well, that's true. I guess a true grump never hums, either. |
| 22:12 | <dglazkov> | a true grump only grumps. |
| 22:13 | Ms2ger | grumps |
| 22:14 | <dglazkov> | Ms2ger: you don't count. You don't really exist. |
| 22:14 | Ms2ger | grumps |
| 22:14 | <dglazkov> | :) |
| 22:15 | <jgraham> | Ms2ger exists, it's just a benevolent AI |
| 22:15 | <TabAtkins> | He's the european instantiation of the BZ algorithm. |
| 22:16 | <TabAtkins> | BZ originally being run, of course, on MIT hardware. |
| 22:16 | <timeless> | happy birthday TabAtkins |
| 22:18 | <TabAtkins> | timeless: Thanks! |
| 22:26 | <dglazkov> | european? I always imagined Ms2ger being from Louisiana or someplace like that. |
| 22:26 | <TabAtkins> | Nah, his timezone is somewhere in europe. |
| 22:27 | <dglazkov> | see? he left. |
| 22:27 | Ms2ger | grumbles at irssi |
| 22:27 | <dglazkov> | it's probably because it's Alligator-hunten time! |
| 22:28 | <Hixie> | aw, nobody sent me their opinions on the duration thing |
| 22:28 | <Ms2ger> | Hixie, nobody cares |
| 22:28 | <Ms2ger> | Sorry |
| 22:28 | <Hixie> | seems that way |
| 22:28 | <hober> | the duration thing? |
| 22:29 | <Hixie> | hober: looking for someone to fill in http://www.whatwg.org/specs/web-apps/current-work/temp and mail it to me :-) |
| 22:29 | <AryehGregor> | Someone with an nvidia.com e-mail address asking questions about the origin of data: URLs? Seems odd. |
| 22:32 | <Hixie> | webkit engineer i believe |
| 22:33 | <AryehGregor> | Ms2ger, by the way, there's something that fails for NodeList on a nightly (trying to poke NodeList.prototype.length): http://aryeh.name/tmp/webapps/DOMCore/tests/submissions/AryehGregor/interfaces.html |
| 22:35 | <AryehGregor> | (or you can use http://w3c-test.org/webapps/DOMCore/tests/submissions/AryehGregor/interfaces.html, if you want something more official-looking) |
| 22:35 | <Ms2ger> | It throws, right? |
| 22:35 | <Ms2ger> | That's per spec |
| 22:35 | <AryehGregor> | Really? |
| 22:35 | <AryehGregor> | Where? |
| 22:35 | <Ms2ger> | It's subtle |
| 22:36 | <TabAtkins> | length is an own property, not gotten fromt eh prototype, I think. |
| 22:36 | <Ms2ger> | TabAtkins, nope |
| 22:36 | <TabAtkins> | Oh, shrug then. |
| 22:36 | <AryehGregor> | WebIDL seems to imply that it's on the prototype. |
| 22:36 | <Ms2ger> | length is a getter that throws if |this| is not a NodeList |
| 22:36 | <Ms2ger> | Which NodeList.prototype isn't |
| 22:36 | <AryehGregor> | Oh. |
| 22:36 | <AryehGregor> | Really? |
| 22:36 | <Ms2ger> | Yep |
| 22:36 | <AryehGregor> | Where does it say that? |
| 22:37 | <Ms2ger> | http://dev.w3.org/2006/webapi/WebIDL/#es-attributes |
| 22:37 | <TabAtkins> | Presumably in the ES spec. |
| 22:37 | <AryehGregor> | DOM4 describes it as a regular old attribute. |
| 22:37 | <heycam> | regular old attributes are all accessor properties on the prototype |
| 22:37 | <Ms2ger> | What heycam said |
| 22:37 | <AryehGregor> | Hmm, right. |
| 22:39 | <AryehGregor> | But I'm not actually getting it, I don't think. |
| 22:39 | <AryehGregor> | Or I'm not intending to. |
| 22:40 | <heycam> | so as Ms2ger says, NodeList.prototype is not a NodeList object |
| 22:40 | <heycam> | it's just a plain object |
| 22:40 | <AryehGregor> | Right, I get that. |
| 22:40 | <AryehGregor> | But I think all I'm doing is calling hasOwnProperty and getOwnPropertyDescriptor on it. |
| 22:40 | <heycam> | the getter for NodeList.prototype.length does a check to see what its this object is |
| 22:40 | <heycam> | if it's not a NodeList, it throws |
| 22:40 | <Ms2ger> | Oh |
| 22:40 | <heycam> | those should succeed... |
| 22:40 | <Ms2ger> | It may be getOPD being broken as well |
| 22:41 | <Ms2ger> | I noticed bholley was looking at that |
| 22:41 | <AryehGregor> | getOwnPropertyDescriptor looks like it's what's throwing. |
| 22:41 | <heycam> | definitely a bug then |
| 22:44 | <AryehGregor> | NodeFilter.prototype doesn't exist in Gecko. o_O |
| 22:44 | <jgraham> | It's not that surprising if the ES5 introspection magic fails with host objects |
| 22:45 | <jgraham> | It does in Opera I believe |
| 22:45 | <heycam> | NodeFilter's a funny one |
| 22:45 | <heycam> | being something intended to be implemented by JS |
| 22:45 | <AryehGregor> | jgraham, well, it's not per spec, so . . . |
| 22:45 | <heycam> | but also something that can be a host object |
| 22:45 | <heycam> | (iirc) |
| 22:45 | <AryehGregor> | Ms2ger, also, you know that the entire prototype chain for Nodes is messed up, right? Everything seems to be on the last prototype object, nothing much is on Node.prototype or Document.prototype or such. |
| 22:46 | <Ms2ger> | Yes |
| 22:46 | <heycam> | or that might be XPathFilter or something |
| 22:46 | <Ms2ger> | That's by design |
| 22:46 | <AryehGregor> | Is that for performance or something? |
| 22:46 | <AryehGregor> | It's causing like half the tests to fail. |
| 22:46 | <Ms2ger> | Dunno, it's an awful design |
| 22:46 | <Ms2ger> | Blame netscape |
| 22:46 | <AryehGregor> | (WebKit fails almost all of them, and IE9 seems to be closest to spec) |
| 22:47 | <jgraham> | AryehGregor: Right, it is a bug |
| 22:47 | <jgraham> | But an unsurprising one given that the ability to do this is rather new |
| 22:48 | <AryehGregor> | Right. |
| 22:48 | <Ms2ger> | Anyway, I expect us to get a lot better in the following 6 months or so |
| 22:50 | AryehGregor | plans to actually test writable/enumerable/configurable-ness, too, not just trust getOPD |
| 22:50 | <jgraham> | Sounds reasonable |
| 22:52 | <AryehGregor> | I wonder how much the web depends on the details of things like whether properties on prototypes are configurable or not. |
| 22:53 | <Ms2ger> | It sure depends on awful things about on* properties |
| 22:53 | <AryehGregor> | Like what? |
| 22:54 | <Ms2ger> | Being able to set them on the prototype and stuff |
| 22:54 | <Ms2ger> | Ask heycam :) |
| 22:55 | <heycam> | AryehGregor, yeah was on old version of prototype that was being used one some sites |
| 22:55 | <heycam> | and it was doing something like Interface.prototype.onsomething = null |
| 22:55 | <AryehGregor> | Whee. |
| 22:56 | <heycam> | so previously when on* things were on the instance, this was basically just doing nothing |
| 22:56 | <heycam> | now with on* being accessors on prototype.... throw |
| 22:59 | AryehGregor | observes that ES seems to be one case where there are clear versions that browsers actually implement completely in a timely fashion, and it seems to work well |
| 22:59 | <heycam> | prefix all the things! |
| 23:00 | <jamesr_> | AryehGregor, really? nobody has ever fully implemented ES3, and nobody can since it's incompatible with the web |
| 23:00 | <jamesr_> | and there aren't any full implementations of ES5 that i'm aware of (although some folks are getting close) |
| 23:00 | <annevk> | Opera fails 1 test |
| 23:01 | <annevk> | but given that ES5 does not include http://wiki.whatwg.org/wiki/Web_ECMAScript it's not really real world compatible :( |
| 23:01 | <jamesr_> | so we're close to having the first ever implementation of a clear version of an ECMAScript |
| 23:03 | <jgraham> | I think that one test we fail is a likely web compat issue |
| 23:04 | <jgraham> | Also, gecko and others implement parts of es.next in an unprefixed (afaik) way |
| 23:04 | <jgraham> | certianly historically gecko has had a bunch of nonstandard stuff |
| 23:05 | <jgraham> | So it isn't really clear that this is an example of clear versions that everyone implements in a timely fashion |
| 23:06 | <jgraham> | (scripting engines are also a bit special because they are very self-contained and typically have dedicated teams working on them) |
| 23:07 | <Hixie> | for duration values: if "1h", "1min", and "1mo" are conforming, but "1m" is not (ambiguous), should a duration of "1hour" be conforming? |
| 23:07 | <jgraham> | Are the i18n people not going to cut out your kidneys? |
| 23:08 | <annevk> | Hixie: I vote for simple first |
| 23:09 | <TabAtkins> | I'm with annevk. min and mo are the only ambiguous case. |
| 23:09 | <TabAtkins> | And if you'd just switch to bimonths that ambiguity would disappear. ^_^ |
| 23:10 | <annevk> | Hixie: we can always allow more syntax later; we have use cases for duration, not for lots of different duration syntax |
| 23:11 | <dglazkov> | annevk: where's the new event constructor syntax doc? linky? |
| 23:12 | <dglazkov> | http://www.w3.org/TR/domcore/#events |
| 23:13 | <dglazkov> | annevk: I answer my own questions |
| 23:17 | <annevk> | great :) |
| 23:17 | <annevk> | nn |
| 23:20 | <gsnedders> | jgraham: I've not read the history, FWIW, but for WebIDL testing see <http://suika.fam.cx/www/webidl2tests/readme>; |
| 23:21 | <gsnedders> | jgraham: Massively outdated, but tests based upon WebIDL, |
| 23:22 | <gsnedders> | AryehGregor: JSC supported all of ES5 except Function.prototype.bind for ages, IE9 doesn't support strict mode. It's far from entirely versioned… |
| 23:23 | <gsnedders> | annevk: Web ECMAScript doesn't actually contradict in ES5. |
| 23:23 | <gsnedders> | annevk: Something supporting all those variants is still a conforming ES5 impl |
| 23:33 | <gsnedders> | heycam: WebIDL is inconsistent: operator getters and attribute getters should have identical behaviour for checking this. |
| 23:37 | <gsnedders> | heycam: I mentioned that in an email forever ago, but I think you missed it |