| 02:10 | <Domenic> | penguin-breeder.org, really jochen__?? |
| 02:11 | <Domenic> | ... huh ok it's a real thing |
| 02:11 | <Domenic> | (I was surprised that your email in bugzilla was at a ... strange ... domain name) |
| 03:41 | <Domenic> | annevk: yeah... I am also feeling discouraged about custom elements now... |
| 04:36 | <Domenic> | This site-wide heading thread is a bit sad |
| 04:36 | <Domenic> | I thought those usually ended up on public-html |
| 06:52 | <annevk> | philipj: Fullscreen: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27865 does this proposal seem reasonable to you? |
| 06:52 | <annevk> | philipj: xidorn is asking me to fix that to unblock unprefixing efforts in Gecko |
| 07:42 | <howdoi> | say we have promise, which has a timeout in it, if we reject the promise, the timeout will not get rejected, which is the best way to handle this? |
| 07:42 | <howdoi> | Domenic's new proposal solves this? |
| 08:25 | <annevk> | howdoi: wrap the rejection? |
| 08:25 | <annevk> | howdoi: so that you can also cancel the timeout? |
| 08:26 | <howdoi> | well, something like canellable promise |
| 08:26 | <howdoi> | ? |
| 08:26 | <annevk> | howdoi: I don't see why that would handle timeouts automatically |
| 08:27 | <howdoi> | hmm |
| 08:27 | <howdoi> | it won't, but on cancelation clearing timeout will be done |
| 08:35 | <annevk> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/718 |
| 08:36 | <annevk> | JakeA: might have helped if some design input from Mozilla was taken |
| 08:37 | <JakeA> | annevk: still believe that SW without fetch is a rarity. Question is how much we should bend over backwards for the math.random case |
| 09:02 | <philipj> | annevk: are you there? I'm a bit confused about something you took from https://github.com/inexorabletash/polyfill/commit/a9f17a7bacc588de674832b47241e22ebf40a676 |
| 09:02 | <annevk> | philipj: okay |
| 09:03 | <philipj> | in the https://dom.spec.whatwg.org/#dom-childnode-replacewith steps, how can the parent change between step 1 and 5? |
| 09:03 | <annevk> | JakeA: it's not exactly bending over backward to make it opt-in |
| 09:03 | <annevk> | JakeA: just like every other service worker feature is |
| 09:03 | <JoWie> | bluebird had cancellable promises |
| 09:03 | <philipj> | annevk: Paritosh says something about mutation events, but the steps in between don't seem to do anything that could fire mutation events |
| 09:04 | <annevk> | philipj: if parent is in nodes |
| 09:04 | <annevk> | oh wait |
| 09:04 | <annevk> | no |
| 09:05 | <philipj> | oh right, the convert step appends to a fragment, but does can that fire an event on any node you already had a reference to? |
| 09:05 | <annevk> | philipj: context object might have been inserted into the DocumentFragment |
| 09:05 | <philipj> | annevk: oh, right |
| 09:05 | <annevk> | this is not taking into account mutation events |
| 09:05 | <annevk> | mutation events are dead to the DOM spec |
| 09:05 | <annevk> | an assumption we might have to revisit at some point I guess |
| 09:05 | <philipj> | annevk: ok, can you maybe add a note in the spec for this not-so-obvious check? |
| 09:06 | <philipj> | I can file an issue if this is not a good time |
| 09:06 | <annevk> | "Note: context object might have been inserted into /node/."? |
| 09:07 | <philipj> | annevk: yeah, sounds good |
| 09:07 | <philipj> | s/might/may/ I guess, but I'm no jgraham |
| 09:07 | <annevk> | I'll make it could |
| 09:07 | <annevk> | may is normative |
| 09:08 | <philipj> | oh right |
| 09:09 | <JoWie> | i could imagine synchronous mutation observation would be very useful for custom elements |
| 09:11 | <annevk> | Hmm, DOM is hitting bikeshed errors again |
| 09:11 | <annevk> | FATAL ERROR: No 'argument' refs found for 'title'. |
| 09:11 | <annevk> | FATAL ERROR: No 'argument' refs found for 'deep' with for='Node/cloneNode(deep)'. |
| 09:12 | <annevk> | I "fixed" the second one, though it seems like a bug in bikeshed, not sure about the first |
| 09:19 | <howdoi> | When can we expect streams in the browser ? |
| 09:19 | <howdoi> | Domenic has a proposal from a very long time, right? |
| 09:20 | <Domenic> | howdoi: they're shipping in Chrome 43+ |
| 09:20 | <Domenic> | and Mozilla announced they will be working on it |
| 09:21 | <annevk> | TabAtkins: I need your help |
| 09:21 | <howdoi> | wow! \o/ that's some good news! Thanks Domenic |
| 09:21 | <annevk> | TabAtkins: something seems screwy around optional arguments |
| 09:22 | <annevk> | philipj: tracked adding a note in https://github.com/whatwg/dom/issues/48 |
| 09:22 | <philipj> | annevk: thanks! |
| 09:27 | <howdoi> | Domenic: I'm on Version 43.0.2357.130, can I check streams out in canary? |
| 09:29 | <Domenic> | howdoi: no need for canary, but it will work there too. See https://googlechrome.github.io/samples/fetch-api/fetch-response-stream.html for a sample. |
| 09:38 | <howdoi> | res.body.getReader() |
| 10:01 | <howdoi> | was looking for readableStream.pipeTo(writableStream) |
| 11:10 | <annevk> | davve: I wonder how you end up with 40l30 as path values there |
| 11:10 | <annevk> | davve: would have assumed three set of coordinates in the range 0-100 |
| 11:10 | <annevk> | davve: for a triangle |
| 11:11 | <annevk> | I'm probably way too nitpicky about these logos though |
| 11:13 | <davve> | annevk: :) I'll try to grab the design savvy guy around before I optimize it too far. |
| 11:13 | <annevk> | Oh wait, now I paste it here I see that 1 is actually an l |
| 11:13 | <annevk> | fonts... |
| 11:14 | <annevk> | Though still a couple coordinates too many |
| 11:28 | <annevk> | philipj: if we give elements a "fullscreen flag", would that not be enough to merge the two stacks? |
| 11:38 | <philipj> | annevk: probably, I'm just wondering if the existing constraints should stay or not |
| 11:39 | <philipj> | making it exactly as forgiving as the top layer rules sounds good to me, unless iframes make that somehow complicated |
| 11:40 | <annevk> | philipj: in #content, Mozilla, xidorn is suggesting we just invent a new value for z-index, "topmost" or some such, and drop ::backdrop for fullscreen... |
| 11:40 | <annevk> | philipj: xidorn will email the WHATWG list with that proposal |
| 11:50 | <philipj> | annevk: I don't see the connection between those things, the backdrop is to make the background black is it not? |
| 11:54 | <annevk> | philipj: well you could style ::backdrop in any number of ways |
| 11:55 | <annevk> | philipj: apparently Chrome and Gecko currently abuse z-index to implement the top layer |
| 11:55 | <annevk> | philipj: so there's not actually a top layer thing, except for <dialog> in Chrome |
| 11:56 | <annevk> | Domenic: I was thinking a bit about the day when IDL is more formalized |
| 11:57 | <annevk> | Domenic: presumably for IDL-defined methods it would have to invoke some kind of algorithm with a predictable name |
| 11:58 | <annevk> | Domenic: so you'd get something like the IDL specification "generating text" that ends up invoking NodeBaseURIGetter(this) for interface Node { readonly attribute DOMString baseURI }; |
| 11:59 | <annevk> | Domenic: or maybe @NodeBaseURIGetter(this) since we'd want it to be internal |
| 12:00 | <annevk> | heycam|away: ^^ |
| 12:00 | <annevk> | I think that's roughly where we want to go. It would also make specifications a lot more predictable in how they are structured and such... |
| 12:06 | <annevk> | Domenic: so anyway, establishing some conventions for all this stuff would be great |
| 12:07 | <annevk> | Domenic: also, if we do this we'd no longer have the problem of people just invoking methods that could be prototyped over by JavaScript, since they'd just refer to the internal algorithms directly |
| 12:07 | <annevk> | Domenic: which incidentally matches what implementations are doing, so makes that clearer too |
| 12:07 | <annevk> | Domenic: so many wins |
| 12:10 | <Domenic> | annevk: hmm, I'd always thought we'd handle that by saying Node instances have a [[baseURI]] internal slot, and baseURI returns that |
| 12:11 | <Domenic> | Then specs would say that they look at node@[[baseURI]] |
| 12:17 | <philipj> | annevk: correct, moving Fullscreen to the top layer in Blink is blocking shipping in Blink too |
| 12:58 | <annevk> | Domenic: so that's the default algorithm for such a thing |
| 12:59 | <annevk> | Domenic: so IDL would probably say if "<var>Class</var><var>Property</var>PropertyGetter" is defined, invoke that, otherwise, return <var>Class</var>@[[<var>Property</var>]]. |
| 13:00 | <annevk> | Domenic: because we have more complicated getters, setters, and method definitions that IDL can't predict |
| 13:02 | <annevk> | I guess I might be alone in finding that all somewhat nice... |
| 13:02 | <annevk> | But it's been kind of a nuisance to me that the interaction between IDL and the rest of the platform is handwavy |
| 13:17 | <annevk> | philipj: so discard what I said earlier about xidorn; he discovered IE is already shipping this so we'll go ahead |
| 13:17 | <annevk> | philipj: I'll make a pass through the spec replacing stack checks with top layer + fullscreen flag checks |
| 13:18 | <annevk> | philipj: I'm a bit sad how much synchronous layout this is, but I guess we had that already anyway |
| 13:40 | <philipj> | annevk: what do you mean? adding and removing things to the top layer doesn't require sync layout does it? |
| 13:40 | <philipj> | it invalidates the layout, sure |
| 13:40 | <philipj> | it seems as long as the spec never says getBoundingClientRect() or some such there shouldn't be a problem? |
| 13:41 | <annevk> | philipj: I guess it depends on where the top layer is |
| 13:41 | <annevk> | philipj: fair |
| 13:42 | <philipj> | annevk: if xidorn says it requires looking at the layout tree in Gecko I'm sure that's correct, it would just be very surprising to me |
| 13:42 | <annevk> | I haven't been talking to xidorn about this, was just considering top layer a layout thing myself |
| 13:43 | <annevk> | Which is probably wrong |
| 14:12 | <JakeA> | Domenic: https://github.com/domenic/cancelable-promise/issues/2 |
| 16:20 | <wanderview> | JakeA: if I do a cache.addAll(urlList) and one of the url's results in a 404... what do you think cache should do? |
| 16:21 | <wanderview> | the spec seems to say it should stick the 404 in the cache |
| 16:21 | <wanderview> | is that expected? |
| 16:21 | <JakeA> | wanderview: yes, else it becomes a mechanism to detect 404s on other origins |
| 16:22 | <wanderview> | JakeA: so evt.waitUntil(cache.addAll(urls)) is not really adequate for installing an app then? |
| 16:22 | <wanderview> | since you might not have actually gotten all of them installed if one hit a 503 or something |
| 16:23 | <JakeA> | wanderview: I agree it's tricky, but you may want to cache a 404 to present to the user while offline |
| 16:23 | <JakeA> | wanderview: I'd have liked it to fail on 404, but security says no (lemmie dig up the ticket) |
| 16:23 | <wanderview> | JakeA: ok... I'm willing to accept it... the WPT test case that verifies success for a non-existent resource just looked weird to me |
| 16:24 | <annevk> | wanderview: I recommend reading the topic :p |
| 16:25 | <wanderview> | JakeA: seems like just always accepting opaque responses and checking status code for other types might be safe? |
| 16:25 | <wanderview> | but whatever |
| 16:25 | <JakeA> | wanderview: I've been thinking about an option to add/addAll that would reject on 404 or any opaque response |
| 16:26 | <annevk> | please make it reject on any non-2xx response in that case |
| 16:26 | <annevk> | that would at least somewhat be founded in primitives |
| 16:26 | <annevk> | or make it an option of sorts |
| 16:26 | <JakeA> | agreed |
| 16:26 | <JakeA> | in fact, wanderview, here's me & you talking about it https://github.com/slightlyoff/ServiceWorker/issues/407#issuecomment-92341768 |
| 16:27 | <JakeA> | annevk: looks like it uses response.ok |
| 16:27 | <annevk> | seems alright |
| 16:28 | <annevk> | ah yeah, as I was saying there it should be an option for request, but I guess addAll could overwrite requests... |
| 16:28 | <wanderview> | annevk: if we hit a cached resource, do we not get a 304? |
| 16:29 | <wanderview> | or is that supposed to be silently converted to 200 using the cached value |
| 16:29 | <JakeA> | wanderview: fetch handles that internally and returns the cached resource |
| 16:29 | <wanderview> | right, ok |
| 16:29 | <annevk> | (unless you have some specific settings) |
| 16:29 | <wanderview> | JakeA: it seems my response on that thread is pretty close to me current "but whatever" |
| 16:30 | <wanderview> | I agree its a bit weird for devs, though |
| 16:33 | <JakeA> | wanderview: yeah, I tried to get the appcache behaviour through, but I think that was seen as a security error that they want to undo |
| 16:34 | <wanderview> | JakeA: annevk: btw, I ran into something in chrome that I was curious if it was spec'd or unique to implementation... I tried to do intercept https://foo.com with http://bar.com and chrome gave me a mixed content warning (should be blocked anyway for opaque navigation) |
| 16:34 | <wanderview> | was just curious about the mixed content thing, though |
| 16:35 | <annevk> | wanderview: I think that's because the SW fetched mixed content |
| 16:35 | <annevk> | wanderview: we should do that too |
| 16:35 | <wanderview> | annevk: but I don't see where that is blocked in the fetch |
| 16:35 | <JakeA> | annevk: shouldn't it just be blocked? |
| 16:35 | <wanderview> | blocked in the spec |
| 16:36 | <annevk> | well before it's blocked it's mixed content |
| 16:36 | <wanderview> | annevk: I mean... if it does a cors request to a http... it should work |
| 16:36 | <JakeA> | annevk: I thought the request would be blocked, so no mixed content happens |
| 16:36 | <annevk> | why would the request be blocked? |
| 16:36 | <JakeA> | Because it's an http request from an https environment |
| 16:36 | <annevk> | in https://fetch.spec.whatwg.org/#http-fetch step 2.2 a network error is returned for that response |
| 16:37 | <annevk> | JakeA: we allow that because of your podcast thing |
| 16:37 | <wanderview> | annevk: thats just for an opaque response, right? if I do a cors mode request to untrusted, it should work right? |
| 16:37 | <annevk> | wanderview: 'request is a client request and response's type is neither "basic" nor "default". ' |
| 16:38 | <annevk> | wanderview: oh CORS |
| 16:38 | <annevk> | wanderview: that is blocked due to mixed content |
| 16:38 | <annevk> | wanderview: in step 4 of https://fetch.spec.whatwg.org/#concept-main-fetch |
| 16:38 | <JakeA> | ahh ok, so no-cors requests are let through? |
| 16:38 | <annevk> | yes, because of you |
| 16:38 | <annevk> | I was kind of hoping we would block those too... |
| 16:39 | <annevk> | (and I guess because it would make upgrading existing sites to use SW even harder) |
| 16:39 | <wanderview> | annevk: thanks |
| 16:39 | <annevk> | (but now we're there I'm not quite sure it was worth it) |
| 16:40 | <annevk> | That you don't even remember how that went down suggests we should maybe reconsider that decision, since it was somewhat controversial at least with some people... |
| 16:40 | <JakeA> | I do remember |
| 16:43 | <JakeA> | Being able to make a mixed request without a window to show the warning in feels wrong though |
| 16:43 | <annevk> | JakeA: sorry, didn't mean for this exchange to happen this way |
| 16:43 | <annevk> | JakeA: yeah, I think we are disallowing that |
| 16:43 | <annevk> | JakeA: although we haven't specified it yet |
| 16:44 | <JakeA> | annevk: this is making me think of event.client.fetch() again |
| 16:45 | <annevk> | JakeA: I'm just gonna hide in a corner now |
| 16:45 | <JakeA> | haha |
| 16:45 | <annevk> | JakeA: I do actually have to go, it seems like you're in the better set of timezones again so we can discuss it tomorrow |
| 16:46 | <JakeA> | annevk: yeah, I'm in UK, will be in the office early tomorrow |
| 19:37 | <Ms2ger> | Anyone have an explanation of why Postel's Law is a disaster handy? |
| 19:42 | <MikeSmith> | Ms2ger: http://cacm.acm.org/magazines/2011/8/114933-the-robustness-principle-reconsidered/fulltext sees sane |
| 19:58 | <Ms2ger> | ekr already pointed at http://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/ |
| 20:09 | MikeSmith | looks |
| 20:10 | <MikeSmith> | wow |
| 20:10 | <MikeSmith> | nice |
| 20:10 | <MikeSmith> | Martin Thomson |
| 21:10 | <TabAtkins> | annevk: I'll look into the Bikeshed errors. Erroring on arguments is *very likely* a Bikeshed bug. On vacation now and gonna head to friends' soon, but I'll get it by tomorrow. |
| 23:43 | <Mateon1> | I was thinking a bit about the await and async keywords. Can you use them on getters and setters? What if you await a function that doesn't return a promise/thenable (is synchronous)? |