| 00:45 | <Domenic> | Couldn't take the D3E thread anymore, had to say something |
| 01:12 | <TabAtkins> | Domenic: You said what we were all thinking (but too jaded to say). |
| 01:57 | <Hixie> | Domenic: there's actually three kinds of features: those that are implemented, those that are not but should be, and those that are not but should not be. |
| 01:57 | <Hixie> | specs must include the former, should include the middle one, and must not include the last one. |
| 01:57 | <SamB> | Hixie: so, um, which category was MNG in before they removed it from mozilla? |
| 01:58 | <Hixie> | the former. |
| 01:58 | <Hixie> | (assuming we pretend that only mozilla existed) |
| 01:59 | <SamB> | ah, so "implemented" is a bit more complicated than a boolean ;-P |
| 01:59 | <Hixie> | nope |
| 01:59 | <Hixie> | showModalDialog() is in that state now |
| 01:59 | <Hixie> | browsers want to drop it |
| 02:00 | <Hixie> | but the specs have to have it |
| 02:00 | <Hixie> | because otherwise there's no definition for how other features should work in conjunction with it while it's implemented |
| 02:01 | <SamB> | hmm, so what category is MNG in *now* I wonder ... or, perhaps more importantly, JNG |
| 02:01 | <Hixie> | one of the last two |
| 02:01 | <SamB> | yes I know that ;-) |
| 02:01 | <Hixie> | deciding which of the last two something is in is a big part of teh job of a spec writer |
| 02:03 | <SamB> | Hmm, is GIF adequately specced? |
| 02:03 | <Hixie> | no |
| 02:04 | <SamB> | thought not |
| 02:04 | <Hixie> | http://wiki.whatwg.org/wiki/GIF |
| 02:06 | <SamB> | hmm, it seems unlikely to be terribly important to include fractint's extensions in spec, except perhaps in order to ensure that they are properly ignored ... |
| 02:06 | <SamB> | I mean, fractint already knows how to handle them, and nobody else is expected to extract the fractal generation parameters from its GIF files |
| 02:11 | <caitp> | you know what would be cool? a spec for nodes on a network to negotiate how to interpret, manipulate and render data from each other |
| 02:13 | <caitp> | and you could test it by teaching two computers to talk to each other using random bit patterns |
| 02:14 | <SamB> | hmm, it says here that there are notes about the extension block structure in loadfile.c ... |
| 02:35 | SamB | adds more info about fractint's extensions to the page despite how obvious it is that browser implementors don't need to do anything special with fractint; it suffices to simply stay away from its clearly-marked extension blocks ... |
| 08:05 | <annevk> | Headers can be simpler than URLSearchParams, there's no need to preserve ordering per HTTP |
| 08:05 | <annevk> | I don't think we need to support bogus servers in the API |
| 08:06 | <annevk> | jungkees: when I click any of the links in https://dvcs.w3.org/hg/xhr there's an error |
| 08:07 | <annevk> | jungkees: did you have a look at https://etherpad.mozilla.org/Request-object-design and the discussion we had on Request objects yesterday? |
| 08:07 | <jungkees> | no I didn't |
| 08:07 | <jungkees> | https://dvcs.w3.org/hg/xhr seems Ok to me? |
| 08:08 | <annevk> | jungkees: e.g. https://dvcs.w3.org/hg/xhr/rev/2654f2bc5a24 returns a 5xx |
| 08:08 | <annevk> | MikeSmith: ^^ |
| 08:09 | <jungkees> | annevk: it's 200 for me |
| 08:11 | <annevk> | jungkees: oh weird, maybe a mirror issue |
| 08:11 | <jungkees> | annevk: I guess so |
| 08:11 | <jungkees> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/242#issuecomment-44620935 |
| 08:12 | <jungkees> | annevk: still need discussion about the hook |
| 08:15 | <annevk> | jungkees: yes, also, JakeA brought up yesterday that he wants to do this: https://gist.github.com/jakearchibald/9f556ce0eafc47ba3d6e |
| 08:15 | <annevk> | jungkees: that seems reasonable, so rather than returning null, I think you want to return the request associated with the Request object |
| 08:16 | <annevk> | jungkees: note, I don't care for the Request object, but it's underlying request is what I'd like to see back |
| 08:17 | <annevk> | jungkees: now, given this setup, the event.default() case is only marginally different. That should return the associated request, as well as a hook that lets me notify the SW when the promise it returns can be resolved |
| 08:18 | <jungkees> | annevk: alright, will revisit it from SW point of view too and get back |
| 08:19 | <annevk> | jungkees: as for waiting for Fetch to do something |
| 08:20 | <MikeSmith> | annevk: jungkees: I just now restarted the web/hg server on dvcs.w3.org so there should be no more 500s for a while |
| 08:20 | <annevk> | jungkees: you could just say "Wait for Fetch to invoke the "handle default response" callback. Then wait for promise X. Then return the value it's resolved/rejected with. |
| 08:20 | <MikeSmith> | but I am seriously going to just drop a bomb on that whole server |
| 08:21 | <MikeSmith> | nobody should be hosting anything in dvcs.w3.org any more |
| 08:21 | <MikeSmith> | jungkees: I recommend moving the repo to github |
| 08:21 | <jungkees> | annevk: you mean from within default() method? |
| 08:22 | <jungkees> | MikeSmith: will talk with the co-editors |
| 08:22 | <jungkees> | MikeSmith: I also prefer to do so |
| 08:23 | <JakeA> | annevk: I'm heading on a cheap holiday to Turkey, I might be dataless, apologies for slow replies until Monday evening |
| 08:23 | <annevk> | jungkees: so handle "handle a fetch" dispatches events (synchronously from the perspective of that algorithm), listeners for those events can invoke default() |
| 08:23 | <annevk> | JakeA: no worries, I'll try to sketch up a HeaderMap and such in the meantime, enjoy |
| 08:24 | <jungkees> | JakeA: enjoy the trip |
| 08:24 | <annevk> | jungkees: probably just before those handlers are invoked you want to set a flag "fine to invoke default() flag" that the algorithm for default() uses |
| 08:25 | <annevk> | jungkees: and then invoking default() itself sets some variable that can be used to resolve/reject the promise it just returned |
| 08:25 | <annevk> | jungkees: then if default() is invoked again, it checks that variable and if its set, it simply rejects |
| 08:30 | <annevk> | jungkees: "handle a fetch" is a weirder asynchronous version of event-dispatch basically |
| 08:30 | <jungkees> | annevk: before "Wait for Fetch to invoke the "handle default response" callback from within the default algorithm, the "handle a fetch" which invoked the listerner for fectch event is already returned with _default_ you say, right? |
| 08:31 | <annevk> | jungkees: you'd return _default_ + callback, then that callback is what gives me the eventual response |
| 08:31 | <annevk> | jungkees: callback is essentially "handle a fetch" minus some of the steps |
| 08:32 | <annevk> | jungkees: the callback is me giving you the response, and you handing back the response that results from the promise dance that it generates |
| 08:32 | <jungkees> | annevk: in which part of the "handle a fetch" should respondWith() run on? |
| 08:33 | <annevk> | jungkees: respondWith should use the same "default can be invoked flag" (should prolly have a more generic name) |
| 08:33 | <annevk> | jungkees: respondWith also then sets a variable for its own promise |
| 08:33 | <annevk> | jungkees: typically "handle a fetch" will return the result of _that_ promise |
| 08:34 | <jungkees> | annevk: I see. so I might have to put together the algorithm again per the discussion |
| 08:34 | <annevk> | jungkees: in the case of default() "handle a fetch" will return a callback to resolve default() return the result of respondWith()'s promise as part of that |
| 08:34 | <annevk> | jungkees: yeah I don't quite understand how you guys imagined the current setup to work |
| 08:35 | <jungkees> | annevk: as I asked, default() re-enters as its own request doesn't make sense? |
| 08:35 | <annevk> | jungkees: I don't see how |
| 08:36 | <jungkees> | annevk: it's nothing but an independent fetch() call with a specially conditioned behavior. no? |
| 08:36 | <annevk> | jungkees: the flow is Fetch -> SW -> default() -> asks Fetch for a Response -> Fetch -> gives SW a response and wants one back |
| 08:37 | <annevk> | jungkees: hmm |
| 08:38 | <annevk> | jungkees: maybe that would work |
| 08:38 | <jungkees> | annvek: what e.default() is doing is just to get a response out of e.request |
| 08:38 | <jungkees> | annevk: and make this algorithm simpler |
| 08:39 | <annevk> | jungkees: okay, so rather than you returning to Fetch when someone invokes default(), you invoke fetch instead |
| 08:39 | <jungkees> | annevk: that's my call |
| 08:39 | <annevk> | jungkees: loosely based on how fetch() works, but |
| 08:39 | <annevk> | jungkees: "that's my idea" is what you mean I think; I think I agree that's a good idea |
| 08:40 | <annevk> | :-) |
| 08:40 | <jungkees> | annevk: :-) |
| 08:40 | <jungkees> | annevk: anyhow, can you think about it? |
| 08:41 | <jungkees> | annevk: If we already have enough information within the Request object to infer this is a default request from SW, it'll be perfect. |
| 08:42 | <annevk> | jungkees: yeah I think that works |
| 08:42 | <jungkees> | annevk: otherwise, we may need a flag |
| 08:42 | <jungkees> | annevk: great |
| 08:42 | <annevk> | jungkees: well yes, we might need a flag on the Request object |
| 08:42 | <annevk> | jungkees: or on request |
| 08:42 | <annevk> | jungkees: otherwise I'd just pass it back into the SW |
| 08:43 | <jungkees> | annevk: I prefer Fetch just returns the final response |
| 08:43 | <annevk> | jungkees: but yeah, the main idea is that the request remains unmodified and if you simply pass it through yourself that works fine |
| 08:43 | <annevk> | jungkees: yeah, Fetch would handle the redirects for sure |
| 08:43 | <jungkees> | annevk: great |
| 08:44 | <annevk> | jungkees: we just need a flag as .client will not be the service worker but the original document |
| 08:44 | <jungkees> | annevk: we have it in FetchEvent now |
| 08:45 | <annevk> | jungkees: maybe we should just use a flag in general, "service worker flag" |
| 08:45 | <annevk> | jungkees: hmm actually, that's icky |
| 08:46 | <annevk> | jungkees: I'll have to think about that a bit more I guess, but the general idea seems sound |
| 08:47 | <jungkees> | annvek: maybe I can leave the .context as-is in the original request instead of setting it to "serviceworker"? |
| 08:47 | <jungkees> | annevk: fetch(request) will set it to "serviceworker" |
| 08:47 | <annevk> | jungkees: yeah, we don't want to change anything from the request |
| 08:47 | <annevk> | jungkees: that's why we need some kind of flag for the .default() case |
| 08:48 | <jungkees> | annevk: exactly. |
| 08:58 | <annevk> | jungkees: added some comments to 242 |
| 08:58 | <annevk> | jungkees: I'll make sure http://fetch.spec.whatwg.org/#fetch-api gets in shape so you can reference it |
| 08:58 | <annevk> | jungkees: any particular constraints I might not be aware of? |
| 08:59 | <jungkees> | annevk: Cool; nothing I can think of now |
| 08:59 | <jungkees> | annevk: let's keep talking |
| 10:02 | <IZh> | Hixie: Hi! In the section "Embedded content" -> "The map element" the example for image map contains four <area> elements with the same coordinates. ;-) |
| 10:21 | <annevk> | jungkees: tobie: JakeA: jgraham: zewt: put up a strawman: http://fetch.spec.whatwg.org/#headermap |
| 10:27 | <jgraham> | I'm not sure what the advantage of making order non-deterministic is. It means that you can't use any third party server API where order happens to matter. |
| 10:47 | <annevk> | jgraham: so you'd have an array and you'd flatten headers that have multiple values into multiple entries? |
| 10:49 | <jgraham> | annevk: I think yes, but I don't know what you mean "flatten". Isn't it just like your proposal but with an array rather than a set? |
| 10:49 | <annevk> | jgraham: no, because if you really want to represent what HTTP can do there's even more |
| 10:49 | <annevk> | Header: value1\nHeader: value2, value 3 |
| 10:50 | <annevk> | Would that become Header: value1\nHeader: value2\nHeader: value 3? |
| 10:51 | <annevk> | biab |
| 10:54 | <jgraham> | I see. Well at least the server APIs I'm familiar with don't expose that difference so it seems less likely that servers will depend on it |
| 11:51 | <annevk> | jgraham: that doesn't really make it clear what the API should be though |
| 11:51 | <jgraham> | davve: Your svg sizing tests are rather slow in Gecko :( I think with <meta name=timeout value=long> they finish in the timeout on my computer, but it's rather close to rely on. |
| 11:52 | <jgraham> | annevk: Conceptually the data structure should be key: [list_of_values], with the API giving special precedence to the first value since in the common case there will be only one |
| 11:53 | <annevk> | jgraham: that's what I came up with |
| 11:54 | <annevk> | jgraham: I do agree it would be nice to define iteration order |
| 11:54 | <annevk> | jgraham: I suspect we should just use insertion order for that |
| 11:54 | <jgraham> | annevk: I was under the impression that the list of values in your API was supposed to be unordered |
| 11:55 | <jgraham> | Yeah |
| 11:55 | <annevk> | jgraham: at the browser level we need to deal with more brokenness |
| 11:55 | <annevk> | jgraham: we need to deal distinctly with the case I gave above |
| 11:58 | <jgraham> | OK |
| 14:14 | <annevk> | zewt: your examples in the toggle bug are a bit confusing |
| 14:27 | <annevk> | http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpHeaderArray.h |
| 14:27 | <annevk> | http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpHeaderArray.cpp |
| 14:27 | <annevk> | so sad |
| 14:35 | <annevk> | https://github.com/slightlyoff/ServiceWorker/issues/300 |
| 17:22 | <annevk> | mathiasbynens: speakerdeck looks nice |
| 17:22 | <annevk> | mathiasbynens: I liked scumbag MySQL :-) |
| 17:28 | <TabAtkins> | MikeSmith: Please let plinss know before you blow up dvcs.w3.org. ^_^ |
| 17:31 | <mathiasbynens> | annevk: :) |
| 18:18 | <annevk> | Domenic: I'd appreciate it if you could take a look at https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923 and see if that code can be simpler or will be better down the road |
| 18:28 | <annevk> | So http://html5.org/r/8651 demonstrates the delay of publishing HTML... To the F5 button |
| 18:28 | <annevk> | Or Cmd+r these days |
| 18:28 | <annevk> | Oh, works now :-) |
| 18:28 | <Hixie> | hm? |
| 18:28 | <annevk> | Hixie: can you update your script to generate the new links at the bottom of Bugzilla bugs? |
| 18:29 | <Hixie> | what? |
| 18:29 | <annevk> | Hixie: html5.org/tools/web-apps-tracker is based on Git, happened the other week |
| 18:29 | <annevk> | Hixie: to fix the hammering on svn.whatwg.org ; I also made the short URLs no longer redirect |
| 18:30 | <Hixie> | the hammering wasn't such a big deal, but whatever you did does seem to have made it faster |
| 18:30 | <Hixie> | the tracker i mean |
| 18:30 | <Hixie> | not the svn repo |
| 18:32 | <annevk> | it wasn't a big deal? |
| 18:32 | <annevk> | you specially asked me about it a couple of weeks back |
| 18:33 | <annevk> | I felt bad so I put half a day into fixing it |
| 18:33 | <annevk> | but yeah, the speed improvements are nice too :-) |
| 18:40 | <Hixie> | oh wow sorry man, i didn't mean to make you feel bad :-) |
| 18:40 | <Hixie> | i just meant that it was likely the source of the slowness :-) |
| 18:41 | <Hixie> | i assumed that caching would have been somewhat trivial |
| 18:41 | <Hixie> | just, check if i've done this particular query before, and if so, read it from disk instead of from the network |
| 18:49 | <bga_> | http://developerblog.redhat.com/2014/05/20/communicating-large-objects-with-web-workers-in-javascript/ |
| 18:49 | <bga_> | still not COW |
| 19:05 | <Domenic> | annevk: cc me so I get an email I can flag as to-do? |
| 19:46 | <hallvors> | heh, the #whatwg link on http://wiki.whatwg.org/wiki/IRC seems to have pointed to the wrong hostname since 2008? should be freenode.net, not .org :-] |
| 19:48 | <Ms2ger> | Ha |
| 19:48 | <hallvors> | nobody who's cool enough to have editing rights on that wiki clicks irc:// links, evidently :) |
| 19:49 | hallvors | clicked mostly to see what clients this computer would suggest |
| 19:50 | <annevk> | Domenic: done |
| 19:51 | <hallvors> | anyway - I have a spec interpretation question regarding window.opener - this may be moot, since there's a bug on changing the spec, but I'd like to <del>come across as a stupid newbie</del><ins>understand how things were supposed to work</ins> |
| 19:51 | <hallvors> | the IDL says attribute WindowProxy? opener; |
| 19:51 | <annevk> | hallvors: oh really, that's sad |
| 19:51 | <annevk> | hallvors: it was just changed to any opener |
| 19:51 | <annevk> | hallvors: fixed the wiki page |
| 19:51 | <hallvors> | so it seems "window.opener" can return only WindowProxy or null |
| 19:51 | <hallvors> | annevk: thanks |
| 19:52 | <Hixie> | spec was just fixed to match browsers |
| 19:52 | <annevk> | hallvors: http://html5.org/r/8652 |
| 19:52 | <hallvors> | I know it's changing :) but I want to understand both versions, and I was confused :-/ |
| 19:53 | <Hixie> | oh |
| 19:53 | <Hixie> | what's the confusion? |
| 19:53 | <hallvors> | so the prose says on setting, for non-null values "must call the [[DefineOwnProperty]] internal method of the Window object" |
| 19:53 | <Hixie> | right |
| 19:53 | <Hixie> | that is black magic |
| 19:53 | <Hixie> | means the IDL no longer gets involved |
| 19:53 | <hallvors> | so .. ah, magic. |
| 19:54 | <hallvors> | so it's not "shadowing" or "overwriting" but just "magic"?? :] |
| 19:55 | <hallvors> | because I assume this means on getting after it was set, you get the new value.. |
| 19:55 | <hallvors> | Hixie: what happens if I do window.opener = 'foo'; delete window.opener; ? |
| 19:55 | <hallvors> | does it revert magically to IDL stuff? |
| 19:56 | hallvors | plans to write a test here |
| 19:57 | <Hixie> | hallvors: hell if i know |
| 19:57 | <Hixie> | hallvors: once you do window.opener = 'foo', everything after that is out of my purview :-) |
| 19:57 | <Hixie> | hallvors: this is mostly ES6/WebIDL questions |
| 19:58 | <annevk> | renewed hope in D3E |
| 19:58 | <annevk> | everyone is a little older and wiser again |
| 19:58 | <hallvors> | Hixie: another question, setting window.opener to null needs to survive navigation. Does the spec actually say that "disowning the opener" persist for any pages loaded into the window, or is it just implied? |
| 19:59 | hallvors | thinks finding the answer in one spec would be hard enough, and now there are three.. |
| 20:20 | <Domenic> | Is mozilla.dev.platform the blink-dev counterpart? |
| 20:20 | <Domenic> | Or, I guess my real question is, are there other Mozilla lists I should pay attention to? |
| 20:27 | <caitp> | according to mdn, yes |
| 20:27 | <caitp> | at least as far as its/iti are concerned |
| 20:31 | <Hixie> | hallvors: the object that "disowns its owner" is the browsing context, not the page |
| 20:34 | <hallvors> | right. I see how it works now. |
| 20:55 | <annevk> | Domenic: that list is worth paying attention to |
| 20:55 | <annevk> | Domenic: maybe https://lists.mozilla.org/listinfo/dev-webapi |
| 20:59 | <caitp> | i like to imagine that there's some gnome somewhere who keeps a list of all the millions of mozilla mailing lists and keeps track of which ones are relevant for which purposes |
| 21:42 | <zewt> | hmm, wonder what this should do (if anything) http://zewt.org/~glenn/test-blob-base-url.html |
| 21:43 | <zewt> | was testing to make sure it didn't use the blob URL itself as a base, but it doesn't attempt any load at all (according to the network inspector) |
| 21:46 | <zewt> | absolute URLs do work, though, maybe it just doesn't have a base URL and gives up during url parsing |