Comments (5)
xiaochengh
commented on June 23, 2024
1
I think an element should be render-blocking if it's parser-inserted, but should stop being render-blocking as soon as it is detached from its tree...
Agreed.
I originally wanted to make "implicit render-blockingness" a stateless thing that can be determined from an element itself. It seems that it has to be maintained as an internal flag on the element that:
- Is initially true if the element is created by parsing the main resource or content added by
document.write - Is initially false in all other cases
- Is set to false if the element is ever detached for any reason
Gecko doesn't block rendering etc on stylesheets with media attributes that don't match for example, or for alternate stylesheets
This part should be fine (or trivially fixable). For example, this part says we block rendering on a <style> only if its media attribute matches. Adding alternate should be trivial.
from html.
emilio
commented on June 23, 2024
In particular, it's easy to track whether an element came from the parser, but not so much which document it came from (that's what the spec says roughly to do).
In particular, current behavior in Gecko for implicitly render-blocking stylesheets is not what the spec says: if you remove and then append a stylesheet back via script, it doesn't remain render-blocking.
It seems blink keeps track of whether the stylesheet came from the parser but not from which parser / document.
from html.
xiaochengh
commented on June 23, 2024
For instance, <style> element parsed in the parser for fragment should not be implicitly potentially render-blocking?
Agreed, this shouldn't be render-blocking.
The current spec is basically a translation of Blink's implementation. Blink's element creation has a flag created_by_parser, and it makes an element render-blocking if the flag is set.
But the flag is also set for fragment parsing... I'll make a test case later to see if there's a bug.
Regarding the spec, the intention is to block on elements directly created by parsing the main resource without involving any scripting. Probably the same as FROM_PARSER_NETWORK in Gecko?
Edit: I'm not sure if an element created by document.write() should be render-blocking. We need some test cases to compare behaviors of different browsers.
from html.
cathiechen
commented on June 23, 2024
For instance, <style> element parsed in the parser for fragment should not be implicitly potentially render-blocking?
Agreed, this shouldn't be render-blocking.
The current spec is basically a translation of Blink's implementation. Blink's element creation has a flag
created_by_parser, and it makes an element render-blocking if the flag is set.But the flag is also set for fragment parsing... I'll make a test case later to see if there's a bug.
Regarding the spec, the intention is to block on elements directly created by parsing the main resource without involving any scripting. Probably the same as
FROM_PARSER_NETWORKin Gecko?
Tested in the following case, it seems FROM_PARSER_NETWORK also include the sub resource, however, we could distinguish them by the nodeInfo, so it would work.
<!DOCTYPE html>
<body>
<iframe src="./style-001.html" width="800" height="600"></iframe>
</body>
</html>
The iframe:
<!DOCTYPE html>
<head>
<style>
@import url(resources/empty_style.css?stylesheet-inline-imported);
</style>
</head>
<body>
<div id="target">
style blocking attr is set to render
</div>
</body>
Edit: I'm not sure if an element created by
document.write()should be render-blocking. We need some test cases to compare behaviors of different browsers.
I don't have a strong opinion about this, but nodes created by document.write are involved in the script, no?
<!DOCTYPE html>
<head>
<meta charset="UTF-8">
<title>Should `document.write` style element be implicitly render-blocking?</title>
<script>
document.write("<style>@import url('support/target-red.css?pipe=trickle(d1)');</style>");
</script>
</head>
<body>
<div class="target">hello</div>
</body>
</html>
from html.
emilio
commented on June 23, 2024
I think an element should be render-blocking if it's parser-inserted, but should stop being render-blocking as soon as it is detached from its tree... document.write-injected stuff should probably be render-blocking. I think that roughly matches Gecko's current (and historical) behavior, FWIW.
But also, implicitly render-blocking links and such are a bit more subtle. Gecko doesn't block rendering etc on stylesheets with media attributes that don't match for example, or for alternate stylesheets, and I don't think we'd want to start doing that.
from html.
Related Issues (20)
- ImageBitmapRenderingContext: clarify behaviour with `premultiplyAlpha: "none"` createImageBitmap option and canvas HOT 2
- Improve DX of element reference attributes by allowing relative references instead of only ids HOT 6
- UI Element Attribute
- align="justify" should align to start, not to left HOT 4
- "Align descendants" believes used margins are altered in overconstrained cases, but that's no longer the case HOT 2
- Clarification on Element reflected IDL attribute steps HOT 9
- Different parsing behavior for "</script>" and "</div>" strings HOT 1
- Nested comment tags. HOT 8
- It's not clear how constraint validation works for FACE if the 'validation anchor' is null HOT 2
- Upcoming WHATNOT meeting on 3/7/2024 HOT 8
- Add a way to automatically get script license and unminified code (if available)
- Clarify context of §4.12.2 the `<noscript>` element HOT 1
- Clarification for nested `kbd` elements
- textarea: attribute for content type
- Provide a mechanism to trigger the fetch of compression dictionaries HOT 9
- Making the WHATNOT meeting cadence weekly HOT 1
- Add `requestClose()` function to HTMLDialogElement HOT 1
- Link rel=modulepreload synchronously fires `load` event if script exists in module map HOT 1
- Worklet termination HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from html.