Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[render-blocking] Fix implicitly-render-blocking definition. #10214

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[render-blocking] Fix implicitly-render-blocking definition. #10214

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
41 changes: 31 additions & 10 deletions source
View file
Open in desktop
Expand Up @@ -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
Copy link
Member

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.

false.</p></li>
</ol>

<p>A <dfn id="insert-an-element-into-a-document" data-x="node is inserted into a document"
Expand Down Expand Up @@ -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
Copy link
Member

Choose a reason for hiding this comment

The 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>

Expand Down Expand Up @@ -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
Copy link
Member

Choose a reason for hiding this comment

The 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>

Expand Down Expand Up @@ -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>

Expand Down Expand Up @@ -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>
Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

The 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
Copy link
Member

Choose a reason for hiding this comment

The 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
Expand Down