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

Document Render-Blocking #886

Open
1 task done
khushalsagar opened this issue Aug 28, 2023 · 10 comments
Open
1 task done

Document Render-Blocking #886

khushalsagar opened this issue Aug 28, 2023 · 10 comments
Assignees
@hober @LeaVerou
Labels
Mode: extra Work done in a dedicated breakout session Review type: CG early review An early review of general direction from a Community Group Venue: WHATWG Venue: WICG
Milestone
2025-01-20-week

Comments

@khushalsagar
Copy link

こんにちは TAG-さん!

I'm requesting a TAG review of Document Render-Blocking.

The Web is designed with a model for incremental rendering. When a Document is loading, the browser can render its intermediate states before fetching all the requisite sub-resources, executing all script or fetching/parsing the complete Document. While this is great to reduce the time for first paint, there is a tradeoff between showing a jarring flash of intermediate Document state (which could be unstyled or have more CLS) vs blocking rendering on high priority sub-resources within a reasonable timeout.

The render-blocking concept helps browsers in making this tradeoff. It lets authors specify the set of stylesheets and script elements which should block rendering. For example, a stylesheet with the rules necessary to ensure a stable layout. But authors can’t specify which nodes should be added to the DOM before first render. This proposal aims to fill this gap.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): HTML
  • The group where standardization of this work is intended to be done ("unknown" if not known): HTML
  • Existing major pieces of multi-stakeholder review or discussion of this design: N/A
  • Major unresolved issues with or opposition to this design: N/A
  • This work is being funded by: N/A

You should also know that...

This feature is needed for cross-browser compliant implementation of cross-document View Transitions, reviewed at #851.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @khushalsagar @noamr.
@khushalsagar khushalsagar added Progress: untriaged Review type: CG early review An early review of general direction from a Community Group labels Aug 28, 2023
@khushalsagar khushalsagar mentioned this issue Aug 28, 2023
Open
@torgo torgo added this to the 2023-09-04-week milestone Aug 30, 2023
@atanassov
Copy link

We'll review the proposal soon. In the meantime I want to draw your attention to #489 and w3c/csswg-drafts#5115 which look like related efforts.

@khushalsagar
Copy link
Author

@atanassov thanks for the pointers. I went through those issues and they don't seem related at first glance. This proposal is about when the first rendering opportunity of a Document happens, which is independent of any steps that happen as a part of the rendering opportunity (flushing style/layout).

Let me know if I missed something, might be easier to discuss once you've had a chance to review the proposal.

@khushalsagar
Copy link
Author

Just a heads up, please do see the discussion at whatwg/html#9332 when reviewing this proposal. A lot of good insightful points have been brought up on the issue.

@torgo torgo modified the milestones: 2023-09-04-week, 2023-10-09-week Oct 8, 2023
@vmpstr
Copy link

vmpstr commented Dec 15, 2023

Hi, please note that we're proposing the following solution: https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md#blocking-element-id

This is in a spec PR here: whatwg/html#9970

@torgo torgo assigned LeaVerou and unassigned atanassov Jan 23, 2024
@martinthomson
Copy link
Contributor

@vmpstr am I to infer that you no longer intend to include the <html blocking="" attribute? I can't see how an HTML document without any body content could end up being unblocked anyway, so that seemed like it was redundant.

I'm also a little surprised at the use of <link relations for this. It seems like it would be cleaner to add a new element type for this. For one, you could have this be slightly more efficient... <block on="section1 section3">.

@plinss
Copy link
Member

plinss commented Feb 19, 2024

Personally I have concerns about adding mechanisms that allow the author to block rendering. Authors will tend to test on faster devices and connections than most users have and are prone to unintentionally making the user's experience worse. (Let's all remember the blank pages people were staring at while fonts downloaded.)

Browsers already make a lot of tradeoffs trying to give the user the best experience, and authors can't predict the user's network conditions or device capabilities. I accept that the browser can't read the author's mind to know which content is more important to the user, so a mechanism that allows the author to set relative priorities rather than forced blocking seems like it would satisfy most of the needs here without the harms.

@noamr
Copy link

noamr commented Feb 19, 2024

Personally I have concerns about adding mechanisms that allow the author to block rendering.

Those exists already, and most of them are far more powerful than render-blocking on an element.

Authors will tend to test on faster devices and connections than most users have and are prone to unintentionally making the user's experience worse. (Let's all remember the blank pages people were staring at while fonts downloaded.)

Browsers already make a lot of tradeoffs trying to give the user the best experience, and authors can't predict the user's network conditions or device capabilities. I accept that the browser can't read the author's mind to know which content is more important to the user, so a mechanism that allows the author to set relative priorities rather than forced blocking seems like it would satisfy most of the needs here without the harms.

This wouldn't work for view-transitions, and a lot of this was discussed at length here.

@noamr
Copy link

noamr commented Feb 19, 2024

@vmpstr am I to infer that you no longer intend to include the <html blocking="" attribute? I can't see how an HTML document without any body content could end up being unblocked anyway, so that seemed like it was redundant.

I'm also a little surprised at the use of <link relations for this. It seems like it would be cleaner to add a new element type for this. For one, you could have this be slightly more efficient... <block on="section1 section3">.

Please let's discuss this at whatwg/html#9332 and not in the TAG repo. The link element was something that approached consensus after about 9 months of discussions.

@vmpstr
Copy link

vmpstr commented Feb 20, 2024

@vmpstr am I to infer that you no longer intend to include the <html blocking="" attribute? I can't see how an HTML document without any body content could end up being unblocked anyway, so that seemed like it was redundant.

Yes, that's correct. We are only planning to support a single way to enable this, namely the section to which I linked above.

As for link vs another tag name, @noamr is right that we seem to have pretty good consensus with a bunch of that discussion happening on the issue. That being said, I don't feel too strongly about a possibility of a different name here, so it may be a worthwhile point to raise. Is there a specific objection to link?

FWIW, I also agree with @noamr that I prefer we take the conversation to the linked issue to make sure the discussion is visible to other participants there

@khushalsagar khushalsagar mentioned this issue Feb 20, 2024
Closed
@khushalsagar
Copy link
Author

@plinss more context on the ViewTransition use-case can also be found here.

@plinss plinss removed this from the 2024-02-19-week milestone Mar 11, 2024
@torgo torgo added this to the 2024-03-18-week milestone Mar 17, 2024
@plinss plinss added the Mode: extra Work done in a dedicated breakout session label Mar 19, 2024
@plinss plinss removed this from the 2024-03-18-week milestone Mar 25, 2024
@plinss plinss mentioned this issue Apr 29, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hober hober

@LeaVerou LeaVerou

Labels
Mode: extra Work done in a dedicated breakout session Review type: CG early review An early review of general direction from a Community Group Venue: WHATWG Venue: WICG
Projects
None yet
Milestone
2025-01-20-week
Development

No branches or pull requests
9 participants
@hober @martinthomson @noamr @LeaVerou @torgo @vmpstr @plinss @atanassov @khushalsagar