Render-blocking: the definition of "created by its node document's parser" is a little bit vague

[cathiechen]

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

[emilio]

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.

[xiaochengh]

For instance,