Intent to Ship: Document Render-Blocking

[Vladimir Levin]

Contact emails

vmp...@chromium.org, nrose...@chromium.org

Explainer

https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md#blocking-element-id

Specification

https://html.spec.whatwg.org/multipage/links.html#link-type-expect

Summary

This feature enables authors to block rendering of a Document until the critical content has been parsed, ensuring a consistent first paint across all browsers. Without this feature, the first paint's state depends on the heuristics for parser yielding which can vary across browsers. This is particularly important for View Transitions where the parsed DOM state on the first frame can drastically change the transition created. Note that this feature specifically implements a `<link rel=expect href="#id">` syntax that allows a link element to reference another expected element on the page. The rendering is then blocked until the expected element is fully parsed. This supersedes previous implementation of html attribute that allows the whole document to be render blocked.

Blink component

Blink>ViewTransitions>MPA

TAG review

https://github.com/w3ctag/design-reviews/issues/886

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

None

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/875)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/245)

Web developers: Positive (https://github.com/whatwg/html/issues/9332) There are some discussions between implementors and developers on this issue. This feature is also a requisite feature for cross-document View Transition adoption, which has strong positive signals (https://daverupert.com/2023/05/getting-started-view-transitions/).

Other signals:

Ergonomics

This feature would be used frequently with cross-document View Transitions, because it allows the browser to wait for necessary content to be parsed.

Activation

This feature can be used directly.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

There are no WebView application risks

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/html/dom/render-blocking?label=master&label=experimental&aligned&q=element-render-blocking Note that we will be renaming these from .tentative shortly

Flag name on chrome://flags

None

Finch feature name

DocumentRenderBlocking

Requires code in //chrome?

False

Adoption expectation

This feature is expected to be adopted by developers using cross-document View Transitions

Estimated milestones

Shipping on desktop

124

Shipping on Android

124

Shipping on WebView

124

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5113053598711808

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUzNfD4MRk0bR1yTZ5F6NzcpETrUU3Vy9GmANZRQd7%3DE4A%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

On Mon, Mar 4, 2024 at 5:36 PM Vladimir Levin <vmp...@chromium.org> wrote:

Contact emails

vmp...@chromium.org, nrose...@chromium.org

Explainer

https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md#blocking-element-id

Thanks for the explainer. It's very useful!!

The explainer mentions console warnings in case authors included an ID that wasn't encountered, resulting in waiting for the fill document.

Was this implemented?

Will render blocking also happen in cases where no transition took place? (e.g. on landing pages)

See question above about console warnings..

Might also be worthwhile to consider a reporting API or a performance observer for this, to enable developers to catch such instances in the wild.

  

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/html/dom/render-blocking?label=master&label=experimental&aligned&q=element-render-blocking Note that we will be renaming these from .tentative shortly

Lots of tests are failing there..

 

Flag name on chrome://flags

None

Finch feature name

DocumentRenderBlocking

Requires code in //chrome?

False

Adoption expectation

This feature is expected to be adopted by developers using cross-document View Transitions

Estimated milestones

Shipping on desktop

124

Shipping on Android

124

Shipping on WebView

124

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5113053598711808

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUzNfD4MRk0bR1yTZ5F6NzcpETrUU3Vy9GmANZRQd7%3DE4A%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MZaRt_2k5-Hny9crxJSgZbgEJau0my%3DW9_7-pp0OqKUw%40mail.gmail.com.

[Noam Rosenthal]

On Wed, Mar 6, 2024 at 10:55 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Mon, Mar 4, 2024 at 5:36 PM Vladimir Levin <vmp...@chromium.org> wrote:

Contact emails

vmp...@chromium.org, nrose...@chromium.org

Explainer

https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md#blocking-element-id

Thanks for the explainer. It's very useful!!

The explainer mentions console warnings in case authors included an ID that wasn't encountered, resulting in waiting for the fill document.

Was this implemented?

It was not, good catch! Opened https://issues.chromium.org/issues/328279707.

Will render blocking also happen in cases where no transition took place? (e.g. on landing pages)

Correct, this feature is not specific to view transitions. It can be used, for example, as a replacement for the existing practice of loading a hidden page and showing it using JS at a particular point. It allows a tradeoff between smoothness and speed, regardless of view transitions.

[Yoav Weiss (@Shopify)]

OK. In this case it might be interesting to think through current use-cases for such initial page hiding (e.g. A/B testing comes to mind) and see how they could be implemented using this and whether this would be a positive change. Did such thinking take place?

 

[Yoav Weiss (@Shopify)]

+Alex N. Jose  +sia.kar...@shopify.com +micah....@optimizely.com +serge...@optimizely.com - This may be of interest from a https://github.com/WICG/ab-worker-prototype perspective.

 

[Noam Rosenthal]

This kind of thinking did take place, though I'm not sure what kind of A/B test you had in mind.

This is merely a declarative way to achieve something that's already doable with JS in multiple ways, so A and B in the A/B test would be identical to users, apart from a slight performance benefit (not calculating styles until we're render-unblocked). Also this behavior is achievable today using <script blocking=render>, but that feels hacky. So in essence this feature is a well-lit path alternative to an existing achievable behavior, which has the benefit of making cross-document view-transitions easier to author.

 

[Yoav Weiss (@Shopify)]

On Wed, Mar 6, 2024 at 12:25 PM Noam Rosenthal <nrose...@chromium.org> wrote:

On Wed, Mar 6, 2024 at 11:10 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Wed, Mar 6, 2024 at 12:04 PM Noam Rosenthal <nrose...@chromium.org> wrote:

On Wed, Mar 6, 2024 at 10:55 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Mon, Mar 4, 2024 at 5:36 PM Vladimir Levin <vmp...@chromium.org> wrote:

Contact emails

vmp...@chromium.org, nrose...@chromium.org

Explainer

https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md#blocking-element-id

Thanks for the explainer. It's very useful!!

The explainer mentions console warnings in case authors included an ID that wasn't encountered, resulting in waiting for the fill document.

Was this implemented?

It was not, good catch! Opened https://issues.chromium.org/issues/328279707.

Will render blocking also happen in cases where no transition took place? (e.g. on landing pages)

Correct, this feature is not specific to view transitions. It can be used, for example, as a replacement for the existing practice of loading a hidden page and showing it using JS at a particular point. It allows a tradeoff between smoothness and speed, regardless of view transitions.

OK. In this case it might be interesting to think through current use-cases for such initial page hiding (e.g. A/B testing comes to mind) and see how they could be implemented using this and whether this would be a positive change. Did such thinking take place?

 

This kind of thinking did take place, though I'm not sure what kind of A/B test you had in mind.

I should've been more specific. The use case I had in mind (but haven't fully thought through) was to avoid anti-flicker snippets in A/B testing. (e.g. by including a non-existent ID in <link rel=expect> and then removing the <link> once the appropriate blocking DOM changes were applied)

[Noam Rosenthal]

g it using JS at a particular point. It allows a tradeoff between smoothness and speed, regardless of view transitions.

OK. In this case it might be interesting to think through current use-cases for such initial page hiding (e.g. A/B testing comes to mind) and see how they could be implemented using this and whether this would be a positive change. Did such thinking take place?

 

This kind of thinking did take place, though I'm not sure what kind of A/B test you had in mind.

I should've been more specific. The use case I had in mind (but haven't fully thought through) was to avoid anti-flicker snippets in A/B testing. (e.g. by including a non-existent ID in <link rel=expect> and then removing the <link> once the appropriate blocking DOM changes were applied)

We can add some examples in the explainer, how some of these anti-flicker use-cases can be implemented using <link rel=expect> instead of those scripts, and the benefit. Would this help move this discussion forward?

[Yoav Weiss (@Shopify)]

That would be useful, thanks!!

[Jake Archibald]

The design of this looks great. Filed a couple of very minor spec nuts https://github.com/whatwg/html/issues/10180

[Vladimir Levin]

Re failing tests:

The flag is currently in "test" status which I don't believe would be picked up by wpt.fyi experimental run. 

Re explainer for non-vt cases:

We added several other examples to the explainer (thanks Noam!)

Re console warning:

Good catch indeed. We'll make sure to address https://issues.chromium.org/issues/328279707 in a timely manner.

On Wed, Mar 6, 2024 at 10:18 AM Jake Archibald <jaffat...@gmail.com> wrote:

The design of this looks great. Filed a couple of very minor spec nuts https://github.com/whatwg/html/issues/10180

Thanks! 🔩

[Mike Taylor]

LGTM1

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2N7%3D1bHWub6UwxgfvSVdrukfhNTDbWaniW88a4rxxd%2BJw%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

LGTM2

On Wed, Mar 6, 2024 at 7:23 PM Mike Taylor <mike...@chromium.org> wrote:

LGTM1

On 3/6/24 11:00 AM, Vladimir Levin wrote:

Re failing tests:

The flag is currently in "test" status which I don't believe would be picked up by wpt.fyi experimental run. 

Re explainer for non-vt cases:

We added several other examples to the explainer (thanks Noam!)

Re console warning:

Good catch indeed. We'll make sure to address https://issues.chromium.org/issues/328279707 in a timely manner.

<webperfwg hat on>

I'd also strongly encourage y'all to also add some reporting on that front.

+Ian Clelland FYI

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/03e4d6cc-b1f5-43f2-825c-f6c8eb28f006%40chromium.org.

[Domenic Denicola]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSLfsS7ZDG3Pe%2B4DDCqT%3DZaRicOvzD5Pwmm544tcFwWP9A%40mail.gmail.com.