-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
[render-blocking] Fix implicitly-render-blocking definition. #10214
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1838,6 +1838,9 @@ a.setAttribute('href', 'https://example.com/'); // change the content attribute | |
<li><p>If <var>removedNode</var>'s <code data-x="attr-popover">popover</code> attribute is not in | ||
the <span data-x="attr-popover-none-state">no popover state</span>, then run the <span>hide | ||
popover algorithm</span> given <var>removedNode</var>, false, false, and false.</p></li> | ||
|
||
<li><p>Set <var>removedNode</var>'s <span>implicitly potentially render-blocking flag</span> to | ||
false.</p></li> | ||
</ol> | ||
|
||
<p>A <dfn id="insert-an-element-into-a-document" data-x="node is inserted into a document" | ||
|
@@ -7763,10 +7766,15 @@ a.setAttribute('href', 'https://example.com/'); // change the content attribute | |
data-x="possible blocking token">possible blocking tokens</span>.</p> | ||
</ol> | ||
|
||
|
||
emilio marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
<p>Elements have an associated boolean <dfn>implicitly potentially render-blocking flag</dfn>, | ||
initially false.</p> | ||
emilio marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
<p>An element is <dfn>potentially render-blocking</dfn> if its <span>blocking tokens set</span> | ||
contains "<code data-x="blocking-token-render">render</code>", or if it is | ||
<dfn>implicitly potentially render-blocking</dfn>, which will be defined at the individual | ||
elements. By default, an element is not <span>implicitly potentially render-blocking</span>.</p> | ||
<dfn>implicitly potentially render-blocking</dfn>. Elements are not <span>implicitly potentially | ||
render-blocking</span> by default.</p> | ||
Comment on lines
+7776
to
+7777
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this meant to reference the boolean state or is this another piece of state or abstraction? |
||
|
||
<h4>Fetch priority attributes</h4> | ||
|
||
|
@@ -17592,8 +17600,12 @@ console.log(style.disabled); // false</code></pre> | |
<p>The <span>child text content</span> of a <code>style</code> element must be that of a | ||
<span>conformant style sheet</span>.</p> | ||
|
||
<p>A <code>style</code> element is <span>implicitly potentially render-blocking</span> if the | ||
element was created by its <span>node document</span>'s parser.</p> | ||
<p>A <code>style</code> element on creation must set its <span>implicitly potentially | ||
render-blocking flag</span> to true if the element was created by its <span>node document</span>'s | ||
parser.</p> | ||
emilio marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
<p>A <code>style</code> element is <span>implicitly potentially render-blocking</span> if its | ||
<span>implicitly potentially render-blocking flag</span> is true.</p> | ||
Comment on lines
+17607
to
+17608
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think we have to say this here. We can just rely on the "potentially render-blocking" definition for element, no? Same for the instances below. |
||
|
||
<hr> | ||
|
||
|
@@ -27728,8 +27740,12 @@ document.body.appendChild(wbr);</code></pre> | |
<p>The default type for resources given by the <code data-x="rel-stylesheet">stylesheet</code> | ||
keyword is <code>text/css</code>.</p> | ||
|
||
<p>A <code>link</code> element of this type is <span>implicitly potentially render-blocking</span> | ||
if the element was created by its <span>node document</span>'s parser.</p> | ||
<p>A <code>link</code> element on creation must set its <span>implicitly potentially | ||
render-blocking flag</span> to true if the element was created by its <span>node document</span>'s | ||
parser.</p> | ||
emilio marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
<p>A <code>link</code> element is <span>implicitly potentially render-blocking</span> if its | ||
<span>implicitly potentially render-blocking flag</span> is true.</p> | ||
|
||
<div w-nodev> | ||
|
||
|
@@ -62237,11 +62253,16 @@ o............A....e | |
|
||
<hr> | ||
|
||
<p>A <code>script</code> element on creation must set its <span>implicitly potentially | ||
render-blocking flag</span> to true if the element was created by its <span>node document</span>'s | ||
parser.</p> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same here. I wonder if we can move all these parser-related requirements to the parser directly. That'd be slightly more explicit. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you know roughly where that'd go, happy to give that a shot. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think in https://html.spec.whatwg.org/#create-an-element-for-the-token would probably make sense. |
||
|
||
<p>A <code>script</code> element <var>el</var> is <span>implicitly potentially | ||
render-blocking</span> if <var>el</var>'s <span data-x="concept-script-type">type</span> is | ||
"<code data-x="">classic</code>", <var>el</var> is <span>parser-inserted</span>, and | ||
<var>el</var> does not have an <code data-x="attr-script-async">async</code> or <code | ||
data-x="attr-script-defer">defer</code> attribute.</p> | ||
render-blocking</span> if <var>el</var>'s <span>implicitly potentially render-blocking flag</span> | ||
slot is true, <var>el</var>'s <span data-x="concept-script-type">type</span> is | ||
"<code data-x="">classic</code>", and <var>el</var> does not have an | ||
<code data-x="attr-script-async">async</code> or <code data-x="attr-script-defer">defer</code> | ||
attribute.</p> | ||
Comment on lines
62260
to
+62265
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, why not allow set it when the conditions are correct? Or does this mean that if once of these things changes, its render-blocking status also changes? |
||
|
||
<p>The <span data-x="concept-node-clone-ext">cloning steps</span> for a <code>script</code> | ||
element <var>el</var> being cloned to a copy <var>copy</var> are to set <var>copy</var>'s | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No flag suffix please for new state.