Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
domenic merged 31 commits intowhatwg:mainfromnoamr:docblock
Feb 27, 2024

Conversation

noamr
Copy link
Collaborator

@noamrnoamr commentedDec 1, 2023
edited by pr-previewbot
Loading

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

Seeexplainer
Closes#9332

(SeeWHATWG 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 )

@noamrnoamr changed the titleWIP: DocblockWIP: document render blocking with a <link> elementDec 13, 2023
@noamrnoamr changed the titleWIP: document render blocking with a <link> elementDocument render blocking with a <link rel=expect> elementDec 15, 2023
@vmpstr
Copy link
Member

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
CollaboratorAuthor

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

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

Copy link
Member

@domenicdomenic 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.

noamr reacted with thumbs up emoji
Copy link
CollaboratorAuthor

@noamrnoamr 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!

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

noamr reacted with thumbs up emoji
Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

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

This is not different fromMediaQueryList 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'smedia attribute's valuematches the environment and el ispotentially render-blocking, thenblock rendering on el.

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

However, if the link is anexternal resource link, then themedia attribute is prescriptive. The user agent must apply the external resource when themedia attribute's valuematches 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 inhttps://html.spec.whatwg.org/#link-type-preload

When themedia attribute of thelink element of anexternal resource link that is alreadybrowsing-context connected, but was previously not obtained due to themedia attribute notmatching the environment, is changed or removed.

This says

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

not when the environment itself changes.

Copy link
CollaboratorAuthor

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 whenmedia changes, ifel'smedia doesn't match the environment, then unblock rendering onel. Which is the opposite of what the note says.

Copy link
CollaboratorAuthor

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 themedia 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 thechange event should fire forMediaQueryList (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.

Copy link
Member

@domenicdomenic left a comment
edited
Loading

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.

noamr reacted with thumbs up emoji
<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.

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 documentdocument, itsindicated part is the result of [selecting the indicated part] givendocument anddocument's [URL].

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@zcorpanzcorpanzcorpan left review comments

@vmpstrvmpstrvmpstr left review comments

@khushalsagarkhushalsagarkhushalsagar left review comments

@domenicdomenicdomenic approved these changes

Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

[View Transitions] Extend render-blocking to support Document
5 participants
@noamr@vmpstr@zcorpan@domenic@khushalsagar

[8]ページ先頭

©2009-2025 Movatter.jp