| 08:24 | <Domenic> | @allstarschh: In general pinging someone less than 24 hours after you've already done so is not necessary. Especially for such a non-urgent PR. I'll try to make time for the PR next week, but it's 17:30 and tomorrow's a holiday, so please have some patience. |
| 08:26 | <@allstarschh> | Domenic: oh, thanks, I saw the reviewer is not set and I don't know if I should set that or someone will set it, the issue is not urgent, |
| 08:46 | <freddy> | Jake Archibald: there's an (early stage) proposal for websites to mark a blob as crossOrigin accessible. https://github.com/w3c/FileAPI/issues/192. In your case, this would require Origin B to opt in. |
| 09:05 | <Jake Archibald> | freddy: isn't that the opposite of what I'm looking for? It seems like the resulting resource would be different-origin to Origin B. |
| 09:07 | <freddy> | Right. 🤦♂️ |
| 09:10 | <Jake Archibald> | I guess that confirms annevk's worry about the property name. It does initially look like it means the opposite. |
| 09:29 | <hsivonen> | The spec describes both classic async scripts and module async scripts as executing as soon as they are available. In reality, classic async scripts may execute a tiny bit later, but since the exact moment of network response finishing isn't exposed, the tiny bit later looks as if it was part of the network timing. However, for inline async module scripts that have no external dependencies, "as soon as they are available" in principle has a well-defined point in time relative to the HTML parse. However, it seems bad to grant special guarantees to that case. Do I understand correctly that the spec doesn't mean to grant guarantees about that special case and it's OK for the parse to progress a bit before an inline async module script without external dependencies executes? |
| 09:30 | <hsivonen> | ^ @allstarschh |
| 09:32 | <hsivonen> | It would be unfortunate to have to use the document.write accommodating execution path in Gecko for inline async module scripts just because the spec granted that special case a special guarantee that goes away as soon as the module has an external dependency. |
| 09:32 | <hsivonen> | (I gather that in any case, module scripts are prohibited from using document.write, so the guarantee would be only about the specific observable DOM shape.) |
| 09:43 | <hsivonen> | Well, at least Chrome doesn't grant that guarantee. I guess I need to file a spec issue to avoid suggesting a specific execution time. |
| 09:46 | <hsivonen> | Demo: https://hsivonen.com/test/moz/inline-async-module-script-without-deps.html |
| 10:05 | <hsivonen> | Filed as https://github.com/whatwg/html/issues/9597 |
| 17:35 | <Eric Portis (he/him)> | Noam Rosenthal: Re: https://github.com/whatwg/html/issues/9332#issuecomment-1673580721, do you have any sense of what % of sites currently render before all of the ~final/stable above-the-fold DOM nodes are in the DOM? I guess 100% of client side rendered sites -- is that the main (only?) use case here? |
| 17:43 | <Noam Rosenthal> | Noam Rosenthal: Re: https://github.com/whatwg/html/issues/9332#issuecomment-1673580721, do you have any sense of what % of sites currently render before all of the ~final/stable above-the-fold DOM nodes are in the DOM? I guess 100% of client side rendered sites -- is that the main (only?) use case here? |
| 17:50 | <Eric Portis (he/him)> | Noam Rosenthal: That makes sense. I'm just trying to get a sense of the need, here -- what's driving this. Paving a bad cowpath (anti-flicker snippets, used for all kinds of reasons) is a cost. |
| 17:52 | <Eric Portis (he/him)> | (And hunt around for a more-scoped solution for the subset of problematic cases) |
| 17:55 | <Noam Rosenthal> | (And hunt around for a more-scoped solution for the subset of problematic cases) |
| 17:58 | <Eric Portis (he/him)> | Right. Something slowly animating out and then popping back in, in the same spot, late is much, much worse than something just popping in late -- I get the extra need for it for View Transitions. But is there a subset of sites that this affects? It's pages that are fetching content in JS, right? I could put a view-transition-name on something at the bottom of HTML spec single-page and it won't matter that the parser has already yielded to the renderer, because that element is a mile outside of the viewport...? |
| 18:05 | <Noam Rosenthal> | Right. Something slowly animating out and then popping back in, in the same spot, late is much, much worse than something just popping in late -- I get the extra need for it for View Transitions. But is there a subset of sites that this affects? It's pages that are fetching content in JS, right? I could put a view-transition-name on something at the bottom of HTML spec single-page and it won't matter that the parser has already yielded to the renderer, because that element is a mile outside of the viewport...? |
| 18:07 | <Eric Portis (he/him)> |
...and those elements have view-transition-names, right? Hypothetically, would this problem be solved if everyone ensured that everything they put a view-transition-name on was in the HTML response. (I know we can't ask authors to do that... just trying to build a mental model of the problem) |
| 18:08 | <Noam Rosenthal> |
|
| 18:09 | <Noam Rosenthal> | I don’t think you and I are talking about the same issue |
| 18:11 | <Noam Rosenthal> | The issue is starting a transition from the old doc before the new one has the elements to transition to. This can happen with zero JS, given chunked HTML responses |
| 18:14 | <Eric Portis (he/him)> | That makes sense, and yeah seems like a significant case I hadn't thought of. So you can't limit this to JS-fetched cases. (Out of curiosity, if you have any data on how often Chrome paints before the last chunk is through, that seems... more attainable than understanding what DOM is "final") |
| 18:15 | <Noam Rosenthal> | Oh that happens super often |
| 18:16 | <Noam Rosenthal> | FCP < domContentLoaded is very common. Not sure those numbers would tell us an important story |
| 18:16 | <Eric Portis (he/him)> | Yeah, ok |
| 18:17 | <Eric Portis (he/him)> | Do you think it makes any kind of sense to tie this to View Transitions? So only block rendering when there's an incoming Transition? |
| 18:18 | <Noam Rosenthal> | No, given that this also helps simpler CLS cases |
| 18:18 | <Noam Rosenthal> | As in, what people do today by changing the body’s display css |
| 18:21 | <Noam Rosenthal> | Also we want to have less vt-specific things whenever possible |
| 18:24 | <Eric Portis (he/him)> | I don't think that's a pattern we want to make more ergonomic = common, but that's just an opinion and I should back it up with something... |
| 18:24 | <Eric Portis (he/him)> | Thanks for the help understanding the issue and where you're coming from on it! |
| 18:25 | <Noam Rosenthal> | Sure! Hope we can reach a resolution |