| 00:42 | <MikeSmith> | https://github.com/delapuente/service-workers-101/#service-workers-101 is very nic |
| 01:53 | <MikeSmith> | https://rawgit.com/delapuente/presentations/eca25220751ae19b5c12edc9ceee2aad075ba7a6/web-platform-when-why/index.html#/ is very nice too |
| 02:07 | <Domenic> | wanderview: I believe that's correct. I think Fetch does? It was needed for some browser off-main-thread use case.… |
| 07:33 | <annevk> | Domenic: FWIW: https://bugs.webkit.org/show_bug.cgi?id=158061 |
| 09:07 | <annevk> | Domenic: so that browsing context name thing was slightly easier to fix than anticipated |
| 09:08 | <annevk> | Domenic: kinda nice after several days of drowning in source browsing contexts |
| 09:09 | <Domenic> | haha yay |
| 09:09 | <Domenic> | Will probably not be able to review until Friday annevk, but we'll see |
| 09:09 | <annevk> | There's absolutely no rush |
| 09:10 | <annevk> | And we should probably get someone to sign off on the exact same origin check and such |
| 10:17 | <Ms2ger> | annevk, hey, https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model seems to have a broken link to fullscreen |
| 10:18 | <annevk> | Ms2ger: you mean that the concept is not integrated? |
| 10:18 | <annevk> | Ms2ger: there's a couple of open issues around that :/ |
| 10:18 | <Ms2ger> | If it's known, that's good enough for me :) |
| 11:08 | <Manishearth> | annevk: ping |
| 11:09 | <annevk> | Manishearth: hey |
| 11:10 | <Manishearth> | annevk: in the fetch spec, what happens in a redirect where the redirecting page itself has some content? |
| 11:10 | <annevk> | Manishearth: nothing much |
| 11:11 | <Manishearth> | annevk: I assume the correc thing to do is to ignore that content |
| 11:11 | <Manishearth> | annevk: but from the spec POV I don't see that happening, both events will continue to queue process response body |
| 11:12 | <annevk> | Manishearth: sure, we can't just cut the connection |
| 11:12 | <annevk> | Manishearth: and if we ever expose redirects we'd want to expose the content they have too |
| 11:12 | <Manishearth> | annevk: afaict they expose their content *right now* |
| 11:12 | <Manishearth> | and conflict with the actual fetch |
| 11:12 | <annevk> | Manishearth: how? |
| 11:13 | <Manishearth> | or |
| 11:13 | <Manishearth> | hm |
| 11:14 | <Manishearth> | ah, I see |
| 11:14 | <Manishearth> | nvm |
| 11:24 | <annevk> | spec wins again :p |
| 11:24 | <annevk> | Seriously though if there's something that could be clarified here let me know |
| 11:52 | <Domenic> | I thought there was a fourth way of getting the global... window, self, frames, ? |
| 11:54 | <jgraham> | Domenic: this |
| 11:54 | <Domenic> | right!! :) |
| 13:16 | <annevk> | I like how despite that being general knowledge, folks will still type frames[0] |
| 13:16 | <annevk> | Including me, though I have tried to correct to use self instead |
| 13:16 | <gsnedders> | idk, I kinda prefer frames[0] simply because it's what we've all always used, so we all instantly know what it is |
| 13:17 | <gsnedders> | I always end up having to check what "self" is. |
| 13:22 | <annevk> | I just found the best way to alert(1) |
| 13:22 | <annevk> | https://github.com/whatwg/html/issues/672 |
| 13:26 | <gsnedders> | so a BOM now overrides the user override encoding? hmmm. not sure I like that. |
| 14:22 | <wanderview> | Domenic: ah, yea... fetch() does indeed use shouldClone=true |
| 14:23 | <annevk> | redirects \o/ |
| 14:42 | <wanderview> | anyone have the Window Insider Preview edge builds? |
| 15:18 | <halindrome> | weird question - are there any modern user agents that still support "user stylesheets" ? |
| 15:19 | <MikeSmith> | Opera does |
| 15:19 | <MikeSmith> | I think, still |
| 15:19 | <halindrome> | MikeSmith: thanks |
| 15:20 | <gsnedders> | halindrome: Firefox does |
| 15:20 | <gsnedders> | halindrome: it's a fixed path in the profile folder, IIRC, but the support is there |
| 15:20 | <gsnedders> | (of course, from there you can use @import url(); etc.) |
| 15:23 | <Ms2ger> | And Stylish |
| 16:29 | <TabAtkins> | annevk: née, not nay |
| 16:33 | astearns | marks the day TabAtkins became a spelling prescriptivist |
| 16:33 | <gsnedders> | tbf, they are entirely different words, and I don't think common usage is against him |
| 16:35 | <tantek> | nor neigh (sound a horse makes) |
| 16:36 | <astearns> | Oh, I agree - and it was good feedback for a non-native speaker. I just found it funny tho |
| 16:38 | <TabAtkins> | I mean, (nay rust) means something else entirely. |
| 16:38 | <TabAtkins> | If we collectively started agreeing that née was spelled "nay", that would be fine. But currently we do distinguish the words. |
| 16:42 | <annevk> | TabAtkins: ta |
| 16:56 | <annevk> | SimonSapin: you might want to follow https://github.com/whatwg/html/issues/1177 and/or give feedback |
| 16:59 | <SimonSapin> | annevk: thanks. Subscribed, but I don’t have more input to this. |
| 17:00 | <SimonSapin> | I agree that it sounds like HTML needs to specify a special case |
| 17:02 | <gsnedders> | annevk: what happens if we make it introduce an empty fragment? but I'd be curious as to quite what browsers do |
| 17:03 | <gsnedders> | I'd be surprised if they had an actual separate state for having a fragment beyond nullability |
| 18:51 | <scshunt> | Hello all! I'm trying to look at some XHR behaviours for implementing an API, and I'm a bit confused by which is the most up-to-date spec. |
| 18:52 | <TabAtkins> | scshunt: https://xhr.spec.whatwg.org/ |
| 18:59 | <scshunt> | TabAtkins: That spec lacks a lot of restrictions that browsers seem to implement, though |
| 19:00 | <scshunt> | like preventing setting certain headers like Host or Expect |
| 19:00 | <TabAtkins> | annevk: ^^^ ? |
| 19:02 | <annevk> | scshunt: that is defined… |
| 19:03 | <annevk> | scshunt: step 5 of setRequestHeader |
| 19:04 | <scshunt> | annevk: thanks! I missed it because it's a separate document :) |
| 19:05 | <annevk> | scshunt: XHR is a thin wrapper around Fetch basically |
| 19:56 | <wanderview> | Domenic: ping |
| 19:59 | <Domenic> | wanderview: on mobile but what's up |
| 20:00 | <wanderview> | Domenic: streams question... I can write an issue up if you prefer... you might be able to just set me straight though |
| 20:02 | <Domenic> | Happy to try IRC |
| 20:02 | <wanderview> | Domenic: ok, in the spec there is a note that while ReadableStreamTee() requires creating 3 functions, an impl could create a class to do it |
| 20:03 | <wanderview> | Domenic: I don't see how that could work since pull() is not called with a `this`... |
| 20:03 | <wanderview> | Domenic: the impl would have to bind() the `this` which is not too different from creating a closure |
| 20:03 | <wanderview> | in costs |
| 20:04 | <wanderview> | Domenic: I was wondering if pull() should get called with the underlyingSource set as its `this` |
| 20:04 | <Domenic> | I think pull is called with this... PromiseInvokeOrNoop? |
| 20:06 | <wanderview> | Domenic: yep, you are correct... thanks! |
| 20:08 | <Domenic> | \o/ |
| 20:09 | <wanderview> | Domenic: if you have specific places in the spec you know that can be optimized... would love to have the list |
| 20:09 | <wanderview> | right now just implementing it pretty literally |
| 20:17 | <Domenic> | wanderview: the other ones we did in chrome were a bit field for all the booleans and the state, and of course not implementing the queue with sizes by summing every time you ask for the total size |
| 20:17 | <Domenic> | I.e. keep a queue and keep a separate running size |
| 20:19 | <wanderview> | Domenic: thanks |
| 20:20 | <wanderview> | Domenic: is there a defined algorithm for "Append to List"? I mean, I can use Array.push() |
| 20:21 | <Domenic> | That's what it means yeah |
| 20:22 | <Domenic> | (Internal array of course.) |
| 20:24 | <wanderview> | ok, thanks |
| 20:38 | <wanderview> | Domenic: hmm, but we don't call cancel with PromiseInvokeOrNoop? |
| 20:38 | <wanderview> | Domenic: oh... @[[Cancel]] is defined as a method |
| 20:38 | <wanderview> | nm |
| 23:22 | <Mek> | hmm, the Worker and SharedWorker constructor definitions have an informative note saying "Any same-origin URL will do", but I don't see any formal spec language that actually enforces any kind of same origin requirement... |
| 23:31 | <Mek> | and firefox and chrome in fact don't agree on behavior for non same-origin urls here either... |
| 23:40 | <Mek> | ah, seems this was an intentional change in the html spec (by moving the check to fetch), but not anything that ever got implemented in chrome, and even firefox is inconsitent about it... |
| 23:46 | <Mek> | but that also means that now (according to the spec) a "module" shared worker with a cross-origin url will be shared between websites on all origins, as there are no further checks to only match against shared workers created from the same origin... |
| 23:50 | <Mek> | actually, it's even worse than that. According the the spec any website can connect to any running shared worker from any other origin, because any kind of origin checks aren't done if an existing worker with the same script url already exists... |
| 23:51 | Mek | files a bug... |