| 00:57 | <Hixie> | looks like once again i'm going to screw the one browser that followed the spec (opera in this case) in order to match the others who are all doing the same thing... |
| 00:57 | <Hixie> | (pushState vs base URLs) |
| 01:01 | <abarth> | frowns |
| 01:02 | <Hixie> | frowns? |
| 01:03 | <abarth> | it's an unfortunate state of afairs |
| 01:03 | <Hixie> | yeah |
| 01:04 | <Hixie> | looks like, however, i might be able to just drop the "document's current address" concept |
| 01:04 | <Hixie> | and just have pushState() change the document's address directly |
| 01:14 | <Hixie> | man, this is huge |
| 01:14 | <Hixie> | the document's current address is dead! long live the now-mutable document's address! |
| 01:54 | <jwalden> | gsnedders: shaving yaks in the way of my patch still, fwiw, just to update on progress |
| 04:56 | <Stephen> | I've got something best represented as a tree of urls. Can anyone speak to the proper use of CollectionPage in this instance? |
| 07:43 | <annevk> | Stephen: what is CollectionPage? If that is Java this might not be the right place |
| 08:17 | <annevk> | heycam: so should we update the DOM with that iterator stuff? |
| 08:17 | <heycam> | annevk, yeah! so for things that are [ArrayClass], nothing needs to be done |
| 08:18 | <heycam> | annevk, can't remember what the state of [ArrayClass] is for NodeList and HTMLCollection |
| 08:18 | <heycam> | annevk, I think those two interfaces at least should have iterators |
| 08:18 | <heycam> | annevk, not sure whether it is worth have NodeList's iterator be a NodeIterator object or not |
| 08:18 | <annevk> | we have it for one of them still |
| 08:18 | <heycam> | annevk, (as jorendorff's suggested) |
| 08:19 | <annevk> | but WebKit hit issues with [ArrayClass] |
| 08:19 | <heycam> | oh :( |
| 08:19 | <heycam> | mind you the iterator stuff hasn't been added to the ES6 spec yet |
| 08:19 | <annevk> | haven't seen much follow up though, so maybe they resolved themselves, but I doubt it |
| 08:19 | <heycam> | although there is agreement in TC39 for it to be added afaik |
| 08:19 | <annevk> | okay |
| 08:19 | <heycam> | what was the issue? |
| 08:19 | <annevk> | I guess I'll file a bug on the iterators then awaiting ES6 |
| 08:19 | <annevk> | heycam: compat iirc |
| 08:20 | <annevk> | let me search my bugmail |
| 08:20 | <heycam> | annevk, sounds good |
| 08:20 | <annevk> | so yeah, it was on NodeList, HTMLCollection nobody thought was feasible, https://bugs.webkit.org/show_bug.cgi?id=81573 is the bug on adding it to NodeList in WebKit |
| 08:21 | <annevk> | heycam: closure broke apparently |
| 08:21 | <annevk> | heycam: always the Google properties that break... |
| 08:21 | <heycam> | heh |
| 08:21 | <heycam> | sigh |
| 08:22 | <annevk> | kudos to them I guess for pushing the platform, but too bad it makes it difficult to change it |
| 08:22 | <heycam> | yeah |
| 08:22 | <heycam> | would be good to know what the specific breakage was |
| 08:23 | <heycam> | to see if it's something fundamental or something that could be worked around |
| 08:24 | <annevk> | yeah, bugs don't say :( |
| 08:25 | <annevk> | arv prolly knows, but is also asleep I guess |
| 08:25 | heycam | CCs himself to the bug |
| 08:27 | <annevk> | oh great, so DOM is discussed on public-script-coord too now |
| 08:27 | <heycam> | as long as it is discussed on a list you're subscribed too... |
| 08:27 | <heycam> | *to |
| 08:28 | <annevk> | I guess |
| 08:28 | <annevk> | which reminds me, I guess I should subscribe to www-style again |
| 08:29 | <annevk> | since crazy won at the W3C (quelle surprise) and we're now using two mailing lists to discuss Fullscreen |
| 08:29 | <heycam> | I'm up to ~2400 unread mails there |
| 08:29 | <annevk> | fffffffuuuuuuuuuuuu |
| 08:30 | <heycam> | speaking of crazy, this is totally my new favourite spec title: https://lists.w3.org/Archives/Member/chairs/2012AprJun/0119.html |
| 08:30 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=17648 is for iterators |
| 08:34 | heycam | goes off to enjoy his friday night |
| 08:40 | <Stephen> | heycam|away: YOur link is pass protected |
| 08:41 | <jgraham> | Stephen: Yeah "Member" in the url is like #secrettreehouse for W3C |
| 08:42 | <annevk> | what's "Team" then? |
| 08:42 | <annevk> | #topofthetree ? |
| 08:42 | <jgraham> | #cabal |
| 08:42 | <annevk> | #secretfloorinthesecrettreehouse |
| 09:04 | <annevk> | Ms2ger: you mean that all interfaces that support that and do not have [ArrayClass] they need to define iterators in prose? |
| 09:05 | <annevk> | Ms2ger: prolly worth cc'ing heycam|away and making the suggestion somewhat more concrete |
| 09:05 | <Ms2ger> | No, that WebIDL puts an iterator() function on the prototype for all interfaces that support indexed properties |
| 09:05 | <Ms2ger> | There's a thread over on script-cord |
| 09:05 | <Ms2ger> | coord* |
| 09:12 | <annevk> | that concluded with heycam|away adding IDL synta |
| 09:12 | <annevk> | x |
| 09:12 | <annevk> | maybe I missed somewhat |
| 09:12 | <annevk> | something* |
| 09:15 | <Ms2ger> | Oh |
| 09:15 | <Ms2ger> | That seems silly |
| 09:16 | <annevk> | fix it |
| 09:17 | <Ms2ger> | I'll put it on my todo list :) |
| 09:28 | <AryehGregor> | Hixie, I'm around now. When you asked me, it was 12:30 AM my time, so . . . |
| 09:30 | <MikeSmith> | Stephen: heycam link was to an announcement of a spec titled "Registration and Discovery of Multimodal Modality Components in Multimodal Systems : Use Cases and Requirements" |
| 10:21 | <jgraham> | "The length IDL attribute on the Window interface must return the number of child browsing contexts that are nested through elements that are in the Document that is the active document of that Window object, if that Window's browsing context shares the same event loop as the script's browsing context of the entry script accessing the IDL attribute; otherwise, it must return zero." |
| 10:22 | <jgraham> | Huh? |
| 10:23 | <jgraham> | a) how do I trigger a situation in which the event loops aren't shared and b) is is really sensible to have implementation details about event loops exposed like this? |
| 10:23 | <jgraham> | I mean, I guess there are other ways it is exposed, but… |
| 10:24 | <zcorpan> | that seems a bit weird |
| 10:25 | <jgraham> | I can't work out how one might end up with a reference to a window using a different event loop |
| 10:25 | <jgraham> | Assuming the UA complies with the "at most one event loop per unit of related browsing context" text |
| 14:07 | <karlcow> | http://www.webkit.org/blog/2082/tim-horton-is-now-a-webkit-reviewer/ |
| 14:07 | <karlcow> | Free (canadian) coffee for the Webkit project? |
| 15:16 | Ms2ger | wonders what a zero-size Blob is good for |
| 15:18 | <Philip`> | For avoiding complex special-casing in algorithms that want to return blobs of variable non-negative sizes? |
| 15:47 | <erlehmann> | hello whatwg |
| 15:48 | <erlehmann> | a friend of mine wishes to make use of rel=feed. i suggested using rel=alternate with an ATOM MIME type. he considers that unclean somehow and hopes to change the standard by not using rel=alternate |
| 15:48 | <hober> | karlcow: he's heard that one before. :) |
| 15:48 | <erlehmann> | what can i say besides “it is not supported anywhere a” |
| 15:49 | <erlehmann> | i argue it is not semantic because the meaning of the predicate is not defined. |
| 15:49 | <karlcow> | hober: I'm pretty sure a million times |
| 15:49 | <erlehmann> | so <link rel=feed href="http://example.org">; would be <this document> <UNKNOWN PREDICATE> <http://example.org>; |
| 15:49 | <erlehmann> | anyone can chime in on that issue? |
| 15:54 | <erlehmann> | anyone can chime in on that issue? |
| 16:04 | <gsnedders> | Anyone have tests for Progress Events? |
| 16:47 | <n00lk0w> | If I include a script on xmpl.com/host.html from xmpl.org/guest.js, what sec context does guest run under? Can it access the cookies from both the xmpl.com and xmpl.org domains? |
| 16:55 | <Philip`> | n00lk0w: <script>s always get run in the origin of the document that they're loaded from |
| 16:55 | <Philip`> | (i.e. the origin http://xmpl.com:80 in your example) |
| 16:58 | <n00lk0w> | Philip`: so, does that mean that if i include a script from google's CDN/jsapi, the request doesn't carry the user's google acct authcookie in the header? |
| 16:58 | <n00lk0w> | and that the google cookie is completely unreadable to the ajax.googleapis.com server? |
| 17:04 | <jgraham> | Philip`: Unless they set document.domain |
| 17:05 | <jgraham> | (which isn't relevant to the case at hand) |
| 17:11 | <Philip`> | n00lk0w: If the user has any cookies associated with ajax.googleapis.com, those will be sent in the HTTP request to that server when loading .js files from it |
| 17:14 | <Philip`> | n00lk0w: The origin thing just means that when the script code is executed on the client, it will have the same security privileges as if it were included directly in the containing document (so it won't have client-side access to cookies from ajax.googleapis.com) |
| 17:40 | <aklein> | smaug____: greetings. do you happen to know what sicking's referring to with his <iframe> paragraph in his latest response re parser-caused mutations? |
| 18:09 | <aklein> | smaug____: (fwiw, I think I found it: http://www.whatwg.org/specs/web-apps/current-work/#scripts-that-modify-the-page-as-it-is-being-parsed) |
| 18:19 | <annevk> | I like that the only way I learn about silly HTML WG things is twitter |
| 18:19 | <annevk> | Edward "HTML bottleneck" O'Connor |
| 18:33 | <hober> | annevk: you know me |
| 18:34 | <smaug____> | aklein: (sorry, it was sauna time.) But yeah, I think sicking meant that. |
| 18:36 | <smaug____> | (and I think sicking is somewhere in Europe atm) |
| 20:10 | <Hixie> | annevk: yt? |
| 23:13 | <gsnedders> | jwalden: Any discussion anywhere/bug report about __proto__ in SM, BTW? |
| 23:14 | <jwalden> | gsnedders: not yet, trying to fly under the radar until I have a completed patch |
| 23:14 | jwalden | has one mostly completed now |
| 23:14 | <gsnedders> | Nice, large clean-up, I guess? :) |
| 23:15 | <jwalden> | not too much, actually |
| 23:15 | <jwalden> | the problem is the current way we do it depends on a lot of incidental side effects |
| 23:15 | <jwalden> | which are not present if we make the stuff proper accessors |
| 23:15 | <gsnedders> | Ah. |
| 23:15 | <jwalden> | also various code that depends on those incidental side effects |
| 23:16 | <jwalden> | brendan is right that it's more work to do it this way, and presents various transition hazards and potential for bugs |
| 23:16 | <jwalden> | doesn't change that it's the right thing to do in the long run, tho |
| 23:17 | <jwalden> | also the current way we're doing it, the current mechanism for properties like that, is quite under-understood, and it's been on my kill list for awhile |
| 23:17 | <jwalden> | although in a longer-term sense, because a lot of stuff used it |
| 23:17 | <gsnedders> | Ah, in our case it wasn't much of a clean-up apart from removing __proto__ special-casing in [[Get]], [[Put]] given we had a single (C++) method that actually did the mutation. |
| 23:17 | <jwalden> | SpiderMonkey is old, and it predates many of the specs |
| 23:17 | <jwalden> | it has a lot of barnacles |
| 23:18 | <jwalden> | far fewer now than six years ago when I first started hacking SpiderMonkey code, but still a bunch |
| 23:18 | <gsnedders> | Yeah, Carakan doesn't really have that disadvantage, given it's only a few years old :) |
| 23:18 | <jwalden> | we have a single method as well |
| 23:18 | <jwalden> | the problem is that single method doesn't also contemplate various access checks needed to safely do/not do the mutation |
| 23:19 | <gsnedders> | Of stuff like circular protos, or? |
| 23:21 | <gsnedders> | (Or stuff like cross-context?) |
| 23:21 | <jwalden> | no, the central method does that |
| 23:21 | <jwalden> | cross-context is the issue |
| 23:21 | <jwalden> | cross-global object more precisely |
| 23:22 | <gsnedders> | Ah. I believe we allow cross-context stuff, but any access will throw. |
| 23:22 | <jwalden> | with the current magic property mechanism, it executes in the context of the object where the "property"'s being set |
| 23:22 | <jwalden> | with accessors, not the case |
| 23:22 | <jwalden> | also there's extra complexity for things like proxies -- Proxy.create(...).__proto__ will never hit the current mechanism, because it'll hit a getPropertyDescriptor trap or whatever, which can only expose accessors or data properties |
| 23:23 | <jwalden> | so an accessor has to tiptoe a little more |
| 23:23 | <gsnedders> | Yeah, not having implemented that yet probably helps :) |
| 23:23 | <jwalden> | likely |
| 23:28 | <gsnedders> | Also: reading up stuff I'd starred on es5-discuss is scary. Stuff like Function.caller not throwing despite being [[Writable]]: false in strict mode in Carakan. |