Intent to Prototype: 'firstrender' event

[David Bokan]

Contact emails

bo...@chromium.org, khusha...@chromium.org, nrose...@chromium.org, vmp...@chromium.org

Explainer

https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md

(See https://github.com/whatwg/html/issues/9315 for design discussion around this event specifically)

Specification

https://drafts.csswg.org/css-view-transitions-2/#pagerevealevent

Summary

The `firstrender` event is fired on a Document's window object at the first render opportunity after a Document is: initially loaded, restored from the back-forward cache, activated from a prerender. It can be used by a page author to setup a page entry UX - such as a ViewTransition from a previous state. This feature is split out from the larger ViewTransition-on-Navigation project.

Blink component

Blink>ViewTransitions

Motivation

This event enables authors to make last-minute DOM changes once a document is ready to be presented but before it is rendered. In particular, this enables an author to setup their style for a ViewTransition, if one is available, from a single convenient place. Without it, authors would have to do this from a `requestAnimationFrame` and also remember to add listen to `pageshow.persisted` to handle the BFCache case, which is error prone. This event is also how a cross-document ViewTransition object is passed into the incoming Document.

Initial public proposal

https://github.com/whatwg/html/issues/9315

Search tags

transition, firstrender, reveal, event, viewtransition

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

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?

None

Debuggability

None

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

No

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1466250

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5205586941837312

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

This is exciting!! (also as a scheduling primitive - e.g. as a way to start loading or executing certain scripts only after the first render)

Are you planning to have the event first more or less at a similar time to when first paint is reported? I'm guessing that we want that event to run after rendering is kicked off (rather than have it delay the first render).

--
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/f0f76584-ea3f-43ab-946c-b920fc064344n%40chromium.org.

[Sangwhan Moon]

This looks useful.

Likely a quick review (I don't see why it would be contentious) so maybe not a big deal, but any reason why there is no TAG review?

On Sep 28, 2023, at 16:27, Yoav Weiss <yoav...@chromium.org> wrote:



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

[Noam Rosenthal]

On Thu, Sep 28, 2023 at 10:28 AM Yoav Weiss <yoav...@chromium.org> wrote:

This is exciting!! (also as a scheduling primitive - e.g. as a way to start loading or executing certain scripts only after the first render)

Are you planning to have the event first more or less at a similar time to when first paint is reported? I'm guessing that we want that event to run after rendering is kicked off (rather than have it delay the first render).

It's planned to be fired at the beginning of the rendering update. It allows you to perform operations that might change the rendering, so yes the script itself would delay the first render if it's a long running script.

[Noam Rosenthal]

On Thu, Sep 28, 2023 at 3:06 PM Sangwhan Moon <s...@chromium.org> wrote:

This looks useful.

Likely a quick review (I don't see why it would be contentious) so maybe not a big deal, but any reason why there is no TAG review?

It was TAG-reviewed as part of CSS view transitions:

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

 

[Sangwhan Moon]

On Sep 28, 2023, at 21:13, Noam Rosenthal <nrose...@chromium.org> wrote:



I see. Is there something that need to be revisited in the template? It should have been linked and marked as complete in this case.

[Noam Rosenthal]

You're right, it was missing there. Fixed.

 

[David Bokan]

On Thu, Sep 28, 2023 at 3:06 PM Sangwhan Moon <s...@chromium.org> wrote:

This looks useful.

Likely a quick review (I don't see why it would be contentious) so maybe not a big deal, but any reason why there is no TAG review?

It was TAG-reviewed as part of CSS view transitions:

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

FYI - we had a quick debate amongst our team about whether that larger review was sufficient for this and decided to ask TAG whether they'd like us to file a separate review. If we do, I'll update the chromestatus entry.

This is exciting!! (also as a scheduling primitive - e.g. as a way to start loading or executing certain scripts only after the first render)

It's technically _before_ the first render so that the author can make modifications knowing they'll be displayed to the user ~immediately.

 

Are you planning to have the event first more or less at a similar time to when first paint is reported? I'm guessing that we want that event to run after rendering is kicked off (rather than have it delay the first render).

I believe it'll be before first paint since it's early in the "update the rendering" steps of the spec and, IIRC, the paint-related metrics measure when pixels change on the display.

We do actually want this to run _before_ rendering so that the event can affect the initial output. For example, to determine what kind of page the navigation is coming from and set up the appropriate CSS view-transition-names. This must happen before the first frame is rendered. Though, as you mention, this does mean authors will have to be somewhat careful not to unnecessarily delay first paint.