whatwg
Render-blocking: the definition of "created by its node document's parser" is a little bit vague
What is the issue with the HTML Standard?
In the Spec, to define implicitly potentially render-blocking there are: For style element:
A style element is implicitly potentially render-blocking if the element was created by its node document's parser.
For link element:
The default type for resources given by the stylesheet keyword is text/css. A link element of this type is implicitly potentially render-blocking if the element was created by its node document's parser.
For the script element:
A script element el is implicitly potentially render-blocking if el's type is "classic", el is parser-inserted, and el does not have an async or defer attribute.
We emphasize that the parser should be created by Document, this constraint looks a little bit vague to me.
And found in Gecko codebase, there are several parsing originations:
enum FromParser {
NOT_FROM_PARSER = 0,
FROM_PARSER_NETWORK = 1,
FROM_PARSER_DOCUMENT_WRITE = 1 << 1,
FROM_PARSER_FRAGMENT = 1 << 2,
FROM_PARSER_XSLT = 1 << 3
};
Would it be more efficient to put the constraint on the parsing originations? For instance, <style> element parsed in the parser for fragment should not be implicitly potentially render-blocking?
WDYT? @emilio @xiaochengh @noamr @zcorpan
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.
For instance,
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.
For instance,
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>
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.
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.