| 16:17 | <domfarolino> | annevk: RE https://github.com/whatwg/fetch/pull/834#issuecomment-439837919; I understand that the PR will add the opaque filter to A->B->A "no-cors" images. Thus HTML will have to penetrate this to get at it. I'm unclear on your last (sentence) though |
| 16:18 | <gsnedders> | I am marginally disappointed that the MDN page for <plaintext> doesn't say it's been obsolete since 1993. |
| 16:34 | <gsnedders> | if I have a document <script>location.href = "http://example.com"</script>; the load event will never fire, right, but it will get readyState fired for complete just before unload? |
| 16:42 | <annevk> | domfarolino: the change would be to not poke through |
| 16:43 | <domfarolino> | annevk: But that would be up to HTML right, to poke through or not? |
| 16:44 | <domfarolino> | was confused with "change things around __here__ if we wanted" |
| 16:47 | <gsnedders> | what valid URL cases end up with identical serialized URL? http://foo.com ends up as http://foo.com/, what else? |
| 16:47 | <gsnedders> | oh, plenty of cases, I'm just searching for the wrong things in the spec |
| 16:54 | <Domenic> | I just retweeted this but realized maybe it's not correct per spec https://twitter.com/_developit/status/1064548725891231745?s=19 isn't innerText supposed to only require style recalc these days? |
| 16:56 | <gsnedders> | Domenic: v. layout? (Twitter isn't loading here for whatever reason.) Yeah, I think that's true. |
| 16:57 | <Domenic> | Yeah versus layout |
| 17:00 | <domfarolino> | annevk: My understanding is that #834 makes it so that A->B->A "no-cors" <img> responses will be opaque. youennf's WPT asserts this, so do we necessarily want HTML to poke through? |
| 17:01 | <domfarolino> | Domenic: I thought it just required style too, but for some reason a lot of things surfacing from a google search indicate people think it requires layout |
| 17:01 | <domfarolino> | Inner text collection steps require CSS "computed values", not sure what that requires though entirely |
| 17:02 | <Domenic> | I think how this happened is that it required layout in WebKit then when Gecko went to standardize it they made a version that only requires style recalc. Blink is working on aligning with spec. No idea about Edge. |
| 17:03 | <gsnedders> | domfarolino: computed values are the output of style, essentially |
| 17:03 | <domfarolino> | That's what I figured |
| 17:03 | <gsnedders> | domfarolino: yeah, I think that's right |
| 17:03 | <gsnedders> | uh, Domenic: ^^ |
| 17:03 | <gsnedders> | There's also the old Presto approach that just returns Element.textContent :) |
| 17:03 | <annevk> | domfarolino: yeah, it would be up to HTML, but I wanna figure that part out too 😊 |
| 17:04 | <gsnedders> | I think the other thing wrt the tweet is people just not realising layout recalc and style recalc can be done separately? |
| 17:05 | <domfarolino> | annevk: Ok that makes sense - is there currently a need right now for HTML to poke through? |
| 17:10 | <domfarolino> | (I think as per current spec the "no-cors" image responses are opaque and thus not "poked through") |
| 17:12 | <annevk> | domfarolino: perhaps, depends on what browsers wanna do, apparently there’s no interop |
| 17:17 | <domfarolino> | annevk: Gotcha. FWIW Chrome is OK with #834's approach, but we want to collect UMAs before impl to see if it might break too much content |
| 17:30 | <annevk> | domfarolino: that PR restores the status quo for fetch(), which I think everyone is aligned on, hence leaving the issue open for the HTML side |
| 17:39 | <domfarolino> | Makes sense. I’d like to see browsers also align on Safari’s treatment of images |
| 19:13 | <domfarolino> | Domenic: This might be a dumb question, but what is the difference between HostResolveImportedModule and ...Dynamically? |
| 19:14 | <Domenic> | domfarolino: HostResolveImportedModule translates (specifier, referencingScriptOrModule) pairs into modules synchronously. It's called a lot from various places in the ES spec. HostImportModuleDynamically actually does the fetch. It's only called by import(). |
| 19:14 | <Domenic> | (and it's async, in a funny way) |
| 19:19 | <domfarolino> | Domenic: Ohh that's why FinishDynamicImport calls HostResolveImportedModule, because HostResolveImportedModuleDynamically actually does the fetching, and the fetching algorithms insert the script into the module map for later reuse by HostResolveImportedModule...that makes sense thanks |
| 19:20 | <Domenic> | Yeah. Would welcome a PR making the flow a bit clearer. |
| 19:20 | <domfarolino> | Thanks a lot for getting to https://github.com/whatwg/html/pull/4181, as I let it slip through the cracks. |
| 19:21 | <domfarolino> | Yeah I'm wondering about how that might be done |
| 19:22 | <Domenic> | Probably too ambitious, but you could imagine a call graph... |
| 19:22 | <domfarolino> | Kinda what I was thinking |
| 19:24 | <Domenic> | Like, `<script type=module>` -> fetch a module script graph -> create a module script -> `import` statement parsing -> HostResolveImportedModule -> resolve a module specifier; `import()` expression -> HostImportModuleDynamically -> resolve a module specifier + FinishDynamicImport -> HostResolveImportedModule -> resolve a module specifier. Or something. Probably more things on each level. |
| 19:56 | <ocket8888_> | Is there an IRC channel where I can ask about HTTP specs? Having a hard time googling it |
| 20:12 | <domfarolino> | Yeah I like the idea of having a graph like that somewhere. Especially for all the script fetching algorithms too (IMSGFP and friends) |