-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug with script-blocking <style> elements #7469
Comments
Wow, that is embarassing! A pull request to fix this would be very welcome. |
Some notes on the parts of the specs that seem problematic to me... The current specs are pretty vague on stylesheet critical subresources... It says
But the CSSOM spec doesn't say anything about it. I can't even find any occurrence of "subresource" in it. As a result, there's no spec on how to create a CSS style sheet for an Besides, in the And there's an inconsistency between |
Yep. This is basically something we've been waiting for the CSS community to help with for some time. #3532 and #2263 are the relevant issues, I think. The former even has some unfinished WPT pull requests, it looks like!
Oh, nice find. I think that's a separate issue from the question of load event timing, which is what we've mostly been focused on so far.
Both style and link just kind of assume that fetching the stylesheet will fetch subresources somehow. Then they set up some stuff to run (about the load event and decrementing the relevant counter) once they've finished loading. Yeah, this is not great. From what I understand @tabatkins recently wrote https://drafts.csswg.org/css-values-4/#fetch-a-style-resource but I don't know who is supposed to call that and whether it applies to There's also https://drafts.csswg.org/cssom/#fetching-css-style-sheets . Historically we've ignored that, having our own spec for fetching stylesheet
That seems reasonable, although we'd need tests to show that. (I.e., tests where Help on any of this stuff would be really welcome!! |
Nah, that was Noam. I presume this is meant to be a generic URL-fetcher for anything CSS related that sets up all the boilerplate for you, and other algos he's written or is writing call into it. I've spent some decent effort trying to dive in and fix all of this, but Fetch's significant under-specification (for usage and guidelines, at least) has stymied me twice now. It also didn't help that HTML's |
There's a subtle difference that And since |
It applies to imports, font-faces, images etc. explicitly - all those specs call |
Of course there is! |
Nice! Who calls "fetch an import"? |
The answer to this question is less nice. It's not called explicitly, but is implied. For imports it can probably be done in a more observable way. For images/fonts etc. this is more challenging - user agents can (and do) make a lot of decisions about when to fetch them, e.g. web fonts are only fetched when there is text in the document that uses the relevant font, and I believe the same goes for SVG shapes and background images. They're not downloaded as soon as the stylesheet is downloaded, but rather wnen the resource is used. Thus, I'm not sure fonts etc. (anything besides CSS imports) can be considered "subresources of the stylesheet". They're perhaps a subresource of the stylesheet+the relevant DOM, and perhaps a consistent way to have them block the load event is to block that event in case the fetch started, regardless of how the fetch was initiated. |
Right. In particular for imports getting this straightened out is important since it affects what's visible in |
Didn't know we have fetch an import. Thanks for the pointer! For the other types of resources, I'm pretty sure fonts are not considered critical subresources, since they should be lazy-loaded on use, so there's no guarantee that they will be loaded. The sitation with images seems worse. Current spec didn't say whether images are critical or not, so I made a test case (https://purring-various-felidae.glitch.me/stylesheet-resources.html) to compare browsers' behaviors. In Chrome, images do not block the In Firefox, it looks like the loading of Anyway, since the spec is intentionally vague on other subresources, maybe we can live with that. But we should at least make imports work. |
If a script-blocking <style> element has critical subresources, we should increment the script-blocking stylesheet counter when we start to fetch those subresources, and decrement the counter when the fetching finishes.
The decrement step is at here, but the increment step seems missing, as none of the references of script-blocking stylesheet counter is related.
The text was updated successfully, but these errors were encountered: