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.

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

Document render blocking with a <link rel=expect> element #9970

Merged
merged 31 commits into from
Feb 27, 2024

Conversation

noamr
Copy link
Contributor

@noamr noamr commented Dec 1, 2023

  • Created <link rel=expect href="#some-element-id" blocking=render>
  • Rendering is blocked on that link, until an element with that ID is fully parsed (closing tag, or programmatically inserted), or until the whole document is fully parsed.

The main use-case for this is delaying a cross-document view-transition for a short period of time to let the new document be more ready.

See explainer
Closes #9332

(See WHATWG Working Mode: Changes for more details.)


/browsing-the-web.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/links.html ( diff )
/parsing.html ( diff )
/semantics.html ( diff )

@noamr noamr changed the title WIP: Docblock WIP: document render blocking with a <link> element Dec 13, 2023
@noamr noamr changed the title WIP: document render blocking with a <link> element Document render blocking with a <link rel=expect> element Dec 15, 2023
@vmpstr
Copy link
Member

vmpstr commented Feb 5, 2024

One thing that we also need is to make sure is that once the opening of <body> is parsed, explicitly or implicitly, then we may no longer add more blocking elements into the set. This is important, since we may already have produced a frame of content before we discover some link element half-way through body, for example.

I didn't see if this PR mentions this situation

@noamr
Copy link
Contributor Author

noamr commented Feb 5, 2024

One thing that we also need is to make sure is that once the opening of <body> is parsed, explicitly or implicitly, then we may no longer add more blocking elements into the set. This is important, since we may already have produced a frame of content before we discover some link element half-way through body, for example.

I didn't see if this PR mentions this situation

This is already in the HTML spec:
https://html.spec.whatwg.org/multipage/dom.html#allows-adding-render-blocking-elements

"A Document document allows adding render-blocking elements if ... the body element of document is null."

Copy link
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't fully worked through the logic here to make sure it makes sense, but here's the mostly-editorial comments.

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
Copy link
Contributor Author

@noamr noamr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed a few of the comments, thanks!

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
<li><p><var>el</var>'s <code data-x="attr-link-href">href</code> attribute is
changed;</p></li>

<li><p>The environment changed and <var>el</var> has a <code
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From implementation perspective, this may be hard to realize because we need to know which environment can change to satisfy or not satisfy a media value. We also need to be future proof about this.

Is there a precedence in the spec for re-checking media attribute if the environment changes? IMHO the ideal think would be to define specific points at which the media attribute is checked (e.g. for rel=expect, when the link element is parsed/encountered) and make the decision whether it applies at that time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's how all existing media attributes work? E.g. viewport width media queries, dark mode...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not different from MediaQueryList change event (https://developer.mozilla.org/en-US/docs/Web/API/MediaQueryList/change_event). Preload links are a precedence you can probably copy from.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's how all existing media attributes work?

I'm trying to find a place where that's spelled out in the spec, do you have a link?

The best I can find in rel=stylesheet fetch setup steps is

If el's media attribute's value matches the environment and el is potentially render-blocking, then block rendering on el.

The only other place I can see is in https://html.spec.whatwg.org/#processing-the-media-attribute (which btw, needs to updated in this PR):

However, if the link is an external resource link, then the media attribute is prescriptive. The user agent must apply the external resource when the media attribute's value matches the environment and the other relevant conditions apply, and must not apply it otherwise.

This is a bit ambiguous. One can read that as "check if media matches the environment when you're about to apply the resource". I'm not sure the interpretation of "anytime environment changes, recheck all media attributes" is clear here. What is the correct reading of this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preload links are a precedence you can probably copy from.

Likewise here, the only relevant text I can find is in https://html.spec.whatwg.org/#link-type-preload

When the media attribute of the link element of an external resource link that is already browsing-context connected, but was previously not obtained due to the media attribute not matching the environment, is changed or removed.

This says

When the media attribute [...] is changed or removed

not when the environment itself changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed it as a requirement and added a note instead

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is just a victim of the general under-specification of link processing, indeed..

I don't understand the new note though. The normative text says that when media changes, if el's media doesn't match the environment, then unblock rendering on el. Which is the opposite of what the note says.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The note is about the environment changing without media changing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For stylesheets, the handling of environment changes for the media attribute should be defined in CSSOM. I'm not sure it actually is, but HTML forwards it to CSSOM.
https://html.spec.whatwg.org/multipage/links.html#link-type-stylesheet%3Aconcept-css-style-sheet-media

CSSOM View defines when the change event should fire for MediaQueryList (which is separate) here: https://drafts.csswg.org/cssom-view-1/#evaluate-media-queries-and-report-changes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unsure where this discussion leaves us but I personally am content with what's currently written because this area feels like an existing problem. @zcorpan, if you have any concerns or concrete suggestions, please let us know.

source Outdated Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
Copy link
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just editorial at this point.

As far as I can tell, for the processing model you've chosen a pretty heavyweight approach of "if anything ever changes, re-process everything". It feels a bit inelegant, but I guess it will definitely work! And it fits the spirit of making specs easy to follow, even if implementations might be more complex.

source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
<li><p><var>el</var>'s <code data-x="attr-link-href">href</code> attribute is
changed;</p></li>

<li><p>The environment changed and <var>el</var> has a <code
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unsure where this discussion leaves us but I personally am content with what's currently written because this area feels like an existing problem. @zcorpan, if you have any concerns or concrete suggestions, please let us know.

source Show resolved Hide resolved
processing model must be followed to determine its <span>indicated part</span>, return the result
of <span data-x="select the indicated part">selecting the indicated part</span> given
<var>document</var> and <var>document</var>'s <span
data-x="concept-document-url">URL</span>.</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Slightly better phrasing:

For an HTML document document, its indicated part is the result of [selecting the indicated part] given document and document's [URL].

source Show resolved Hide resolved
source Show resolved Hide resolved
@domenic domenic merged commit bcb3b9a into whatwg:main Feb 27, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

[View Transitions] Extend render-blocking to support Document
5 participants