-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Conversation
This reverts commit d70a7a0.
One thing that we also need is to make sure is that once the opening of I didn't see if this PR mentions this situation |
This is already in the HTML spec: "A Document document allows adding render-blocking elements if ... the body element of document is null." |
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.
Haven't fully worked through the logic here to make sure it makes sense, but here's the mostly-editorial comments.
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.
Fixed a few of the comments, thanks!
<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 |
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.
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.
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.
That's how all existing media attributes work? E.g. viewport width media queries, dark mode...
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.
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.
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.
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?
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.
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.
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.
Removed it as a requirement and added a note instead
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.
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.
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.
The note is about the environment changing without media changing.
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.
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
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.
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.
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.
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.
<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 |
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.
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.
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> |
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.
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].
<link rel=expect href="#some-element-id" blocking=render>
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 )