| 13:17 | <MikeSmith> | annevk: https://stackoverflow.com/questions/52518370/transparent-movement-of-cors-enabled-resources-with-cross-origin-redirect |
| 13:18 | <MikeSmith> | > I'd need to be able to tell the browser to send credentials to old.example.com but once it redirects you to new.example.com, request it without credentials / in no-cors mode. As far as I know that's not possible -- the initial request and all following redirects get the same fetch options. Am I missing something? Is there another way to accomplish this? |
| 13:32 | <annevk> | MikeSmith: replied |
| 13:33 | <MikeSmith> | thanks! |
| 14:39 | <lgrahl> | o/ |
| 14:40 | <lgrahl> | Quick question for WebSocket: When calling .close, the 'close' event should not fire as a result, right? |
| 14:41 | <nox> | lgrahl: https://html.spec.whatwg.org/multipage/web-sockets.html#dom-websocket-close It depends. |
| 14:44 | <lgrahl> | nox: Ok... what if I'm connected, I call .close and once the closing handshake completes, the 'close' event fires. What close code will I get in that event? |
| 14:47 | <lgrahl> | What I'm on about: How would I know whether the close code came from me initiating the closing handshake or from the server? |
| 14:50 | <lgrahl> | Also: "The code attribute must return the value it was initialized to. It represents the WebSocket connection close code provided by the server." |
| 15:21 | <domfarolino> | Does anyone else experience this? When I paste this exact link into Chrome's URL bar and hit enter, it google searches for the link, instead of navigating to the page: https://w3c.github.io/preload/ (but without the trailing `/`, it navigates fine) |
| 15:23 | <gsnedders> | domfarolino: doesn't repro here? |
| 15:25 | <domfarolino> | and of course it isn't for me anymore. It did like 10 times in a row though, odd. |
| 15:41 | <gsnedders> | hah! |
| 15:41 | <gsnedders> | yeah, I've definitely seen weirdness like this in multiple browsers. |
| 16:10 | <lgrahl> | Ugh, still stubbornly ignore the streams API... https://github.com/w3c/webrtc-quic/issues/63 |
| 20:41 | <domfarolino> | eeeps: how will the HTML example in the issue you replied on only load a single image? |
| 20:42 | <domfarolino> | The rel=preload shouldn’t know about any other elements in the page. It’s job is just to load what it describes. And the first link described a potentially-media-matching image derived from a source set, and the second describes an always-media-marching image from a source set right? |
| 20:48 | <eeeps> | When both <source>s are wrapped within a <picture>, the second one is ignored if the first one matches. Here's a non-normative part of the spec that says as much -- https://html.spec.whatwg.org/multipage/images.html#introduction-3:art-direction-3 -- zcorpan would know better than I where to find it normatively |
| 20:50 | <eeeps> | So, yeah, in order to preload just one, you'd have to modify your <link media>s to make them mutually exclusive, because as you say, the <link>s wouldn't know about the <picture> context |
| 20:53 | <eeeps> | If we figure out some way for the `<link>`s to know about that context, it saves authors from having to modify their `media`s, and would allow preloading resources for image-format based selection (`<picture><source type>`). Not sure if those use cases are worth the complexity this would add to <link> though. |
| 20:56 | <domfarolino> | Btw the normative part you’re looking for is https://html.spec.whatwg.org/multipage/images.html#updating-the-source-set |
| 20:56 | <eeeps> | 👍 |
| 20:57 | <domfarolino> | Ok so you’re saying we’d preload two images, when that might not be necessary at all |
| 20:59 | <eeeps> | Right -- if you just copy the medias from the <source>s in the example to <link>s, you sometimes preload both resources. But the <picture> on its own would only ever load one. |
| 21:03 | <domfarolino> | That makes sense. I was confused by “HTML in the example will load only one image”. Makes sense you were referring to the <picture> HTML tho. I agree that is an awkward problem hmm |
| 21:06 | <eeeps> | Asking authors to modify medias to be mutually exclusive might not be a terrible solution? Again, not sure what to do about type, other than add some mechanism so that the <link>s are grouped and processed together somehow, as the <source>s will be later. |
| 22:03 | <domfarolino> | eeeps: Ahh, the confusion earlier (my bad!) was that we were talking about two different HTML snippets it seems. Hmm, yeah asking authors to do that might not be too bad. I wonder how bad it would be if they took no action though, and every preload loaded (aka how many image requests on average would be wasted) |
| 22:18 | <eeeps> | I mean, if that number is significant, preloading useless resources is an unconscionable crime against performance, and if it's insignificant, why are you art directing in the first place? |
| 22:19 | <eeeps> | and I assure you, if there was any confusing communication going on, it was almost certainly my bad (: |
| 23:15 | <domfarolino> | We’ll have to consider ways to make certain preloads not load then. Interesting, since right now preloads are “mandatory” fetches. |