CSSWG Minutes Telecon (2024-08-21) | CSS-Tips

View Transitions are one of the crucial superior options CSS has shipped in latest occasions. Its title is self-explanatory: transitions between views are doable with simply CSS, even throughout pages of the identical origin! What’s extra fascinating is its subtext, since there isn’t a must create advanced SPA with routing simply to get these eye-catching transitions between pages.

What additionally makes View Transitions wonderful is how rapidly it has gone from its first public draft again in October 2022 to transport in browsers and even in some manufacturing contexts like Airbnb — one thing that doesn’t occur to each function coming to CSS, so it reveals how rightfully hyped it’s.

That mentioned, the API remains to be new, so it’s sure to have some edge instances or bugs being solved as they arrive. An fascinating approach to sustain with the newest developments about CSS options like View Transitions is immediately from the CSS Telecom Minutes (you may subscribe to them at W3C.org).

View Transitions had been the first focus on the August 21 assembly, which had a lengthy agenda to handle. It began with a lightweight bug in Chrome concerning the navigation descriptor, utilized in each cross-document view transition to opt-in to a view transition.

@view-transition  none;

At the moment, the specs outline navigation as an enum sort (a set of predefined varieties), however Blink takes it as a CSSOMString (any string). Whereas this initially was handed as a bug, it’s fascinating to see the dialog it sparked on the GitHub Problem:

Really I feel that is debatable, we don’t at present have at guidelines that use enums in that means, and often CSSOM doesn’t attempt to be absolutely type-safe on this means. e.g. if we add new navigation varieties and a few browsers don’t help them, this could interpret them as invalid guidelines reasonably than guidelines with empty navigation.

The final assertion could not look thrilling, but it surely opens the opportunity of new navigation varieties past auto and none, so take into consideration what a special sort of view transition may do.

After which onto the CSSWG Minutes:

emilio: Is it helpful to distinguish between lacking auto or none?

noamr: Sure, essential for ahead compat. If one browser provides one other sort that others don’t have but, then we wish to see that there’s a distinction between none or invalid

emilio: However then you definately get auto conduct?

noamr: No, the unknown worth will not be learn for objective of nav. It’s a vt function with out navigation descriptor and no preliminary worth Just like having invalid rule

So in future implementations, an invalid navigation descriptor can be ignored, however precisely how remains to be below debate:

ntim: How is it totally different from navigation none?

noamr: Auto vs invalid after which auto vs none. None would supersede auto; it has a that means to not do a nav whereas invalid is a no-op.

ntim: So none cancels the nav from the prev doc?

noamr: Sure

The none has the intent to cancel any view transitions from a earlier doc, whereas an invalid or empty string can be ignored. Ultimately, it resolved to return an empty string if it’s lacking or invalid.

RESOLVED: navigation is a CSSOMString, it returns an empty string when navigation descriptor is lacking or invalid

Onto the following merchandise on the agenda. The dialogue went into the view-transition-group property and whether or not it ought to have an order of priority. To not confuse with the pseudo-element of the identical identify (::view-transition-group) the view-transition-group property was resolved to be added someplace sooner or later. As of proper now, the tree of pseudo-elements created by view transitions is flattened:

::view-transition
├─ ::view-transition-group(name-1)
│  └─ ::view-transition-image-pair(name-1)
│     ├─ ::view-transition-old(name-1)
│     └─ ::view-transition-new(name-1)
├─ ::view-transition-group(name-2)
│  └─ ::view-transition-image-pair(name-2)
│     ├─ ::view-transition-old(name-2)
│     └─ ::view-transition-new(name-2)
│ /* and so one... */

Nevertheless, we could wish to nest transition teams into one another for extra advanced transitions, leading to a tree with ::view-transition-group inside others ::view-transition-group, like the next:

::view-transition
├─ ::view-transition-group(container-a)
│  ├─ ::view-transition-group(name-1)
│  └─ ::view-transition-group(name-2)
└─ ::view-transition-group(container-b)
    ├─ ::view-transition-group(name-1)
    └─ ::view-transition-group(name-2)

So the view-transition-group property was born, or to be exact, it will likely be sooner or later in timer. It would look one thing near the next syntax if I’m following alongside appropriately:

view-transition-group: regular | <ident> | nearest | comprise;

• regular is contained by the foundation ::view-transition (present conduct).
• <ident> can be contained by a component with an identical view-transition-name
• nearest can be contained by its nearest ancestor with view-transition-name.
• comprise will comprise all its descendants with out altering the component’s place within the tree

The values appear easy, however they’ll battle with one another. Think about the next nested construction:

A  /* view-transition-name: foo */
└─ B /* view-transition-group: comprise */
   └─ C /* view-transition-group: foo */

Right here, B needs to comprise C, however C explicitly says it needs to be contained by A. So, which wins?

vmpstr: Concerning nesting with view-transition-group, it takes key phrases or ident. Include says that all the view-transition descendants are nested. Ident says identical factor but additionally component itself will nest on the factor with that ident. Query is what occurs if a component has a view-transition-group with a customized ident and likewise has an ancestor set to comprise – the place can we nest this? the comprise one or the one with the ident? noam and I agree that ident ought to most likely win, appears extra particular.

<khush>: +1

The conversations continued if there needs to be a comprise key phrase that wins over <ident>

emilio: Agree that this appears fascinating. Is there any use case for truly implementing the containment? Do we want a powerful comprise? I don’t assume so?

astearns: Someplace alongside the road of including a brand new key phrase equivalent to contain-idents?

<fantasai>: “contain-all”

emilio: Yeah, like sth to comprise all the pieces however wants a use case

However for now, it was set for <ident> to have extra specificity than comprise

PROPOSED RESOLUTION: idents take priority over comprise in view-transition-group

astearns: objections or considerations or questions?

<fantasai>: simply as they do for <ident> values. (which additionally apply containment, however solely to ‘regular’ parts)

RESOLVED: idents take priority over comprise in view-transition-group

Lastly, the principle course of the dialogue: whether or not or not some properties needs to be captured as kinds as an alternative of as a snapshot. Proper now, view transitions work by taking a snapshot of the “previous” view and transitioning to the “new” web page. Nevertheless, not all the pieces is baked into the snapshot; some related properties are saved to allow them to be animated extra fastidiously.

From the spec:

Nevertheless, properties like mix-blend-mode which outline how the component attracts when it’s embedded can’t be utilized to its picture. Such properties are utilized to the component’s corresponding ::view-transition-group() pseudo-element, which is supposed to generate a field equal to the component.

Briefly, some properties that depend upon the component’s container are utilized to the ::view-transition-group reasonably than ::view-transition-image-pair(). Since, sooner or later, we may nest teams inside teams, how we seize these properties has much more nuance.

noamr: Greatest situation we wish to focus on immediately, how we seize and show nested parts but additionally applies to non-nested view transition parts derived from the nested dialog. Once we nest teams, some CSS properties that had been beforehand not that essential to seize at the moment are essential as a result of in any other case it appears damaged. Two teams: tree results like opacity, masks, clip-path, filters, perspective, these apply to complete tree; borders and border-radius as a result of after you have a hierarchy of teams, and you’ve got overflow then the overflow impacts the origin the place you draw the borders and shadows these additionally paint after backgrounds

noamr: We see three choices.

1. Change all the pieces by default and don’t simply seize snapshot however add extra issues that get captured as ?? as an alternative of a flat snapshot (opacity, filter, rework, bg borders). Will change issues as a result of these kinds are a part of the group however have modified issues earlier than (however that is totally different because it modifications observable computed type)
2. Add new property view-transition-style or view-transition-capture-mode. Fan of the primary because it jogs my memory of transform-style.
3. To have this new property however give it auto worth. If group accommodates different teams while you get the brand new mode so customers utilizing nesting get the brand new mode however can have a property to vary the conduct If individuals need the previous crossfade conduct they’ll at all times achieve this by common DOM nesting

Concerning the primary possibility about altering how all view transitions seize properties by default:

bramus: Sure, this could be breaking, however it will break in a great way. Concerning the identify of the property, one of many values proposed is cross-fade, which is a worth I wouldn’t suggest as a result of authors can change the animation, e.g. to scale-up/ scale-down, and so on. I’d recommend a special identify for the property, view-transition-capture-mode: flat | layered

After all, altering how view transitions work is a dilemma to actually take into consideration:

noamr: There’s some sentiment to 1 however I really feel individuals want to consider this extra?

astearns: Might resolve on possibility 1 and have blink strive it out to see how a lot breakage there may be and if its manageable then we’re good and are available again to this. Could be resolving one 1 until it’s not doable. I’d reasonably not outline a brand new seize mode with out a change

…so the very best plan of action was to assemble extra knowledge and determine:

khush: Once we prototype we’ll discover edge instances. We’ll take these again to the WG in that case. Wish to get this proper

noamr: It includes a number of CSS props. A few of them are captured and never painted, whereas others are painted. Those particularly would all be specified

After some extra dialogue, it was resolved to come back again with compat knowledge from browsers, you may learn the full minutes at W3C.org. I wager there are a number of fascinating issues I missed, so I encourage you to learn it.

RESOLVED: Change the seize mode for all view-transitions and specify how every property is affected by this seize mode change

RESOLVED: Describe categorization of properties within the Module Interactions sections of every spec

RESOLVED: Blink will experiment and are available again with modifications wanted if there are compat considerations