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

View Transitions are some of the superior options CSS has shipped in current occasions. Its title is self-explanatory: transitions between views are potential with simply CSS, even throughout pages of the identical origin! What’s extra fascinating is its subtext, since there is no such thing as a have to 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 delivery in browsers and even in some manufacturing contexts like Airbnb — one thing that doesn’t occur to each characteristic coming to CSS, so it reveals how rightfully hyped it’s.

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

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

@view-transition  none;

At present, 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 Situation:

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

The final assertion could not look thrilling, nevertheless it opens the opportunity of new navigation varieties past auto and none, so take into consideration what a unique sort of view transition might 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 need to see that there’s a distinction between none or invalid

emilio: However you then get auto conduct?

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

So in future implementations, an invalid navigation descriptor will likely be ignored, however precisely how continues to be beneath debate:

ntim: How is it completely different from navigation none?

noamr: Auto vs invalid after which auto vs none. None would supersede auto; it has a which 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 will likely be ignored. In the long run, 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 need 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, will probably be sooner or later in timer. It’d look one thing near the next syntax if I’m following alongside accurately:

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

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

The values appear easy, however they will 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 desires to comprise C, however C explicitly says it desires to be contained by A. So, which wins?

vmpstr: Concerning nesting with view-transition-group, it takes key phrases or ident. Comprise says that the entire view-transition descendants are nested. Ident says identical factor but additionally factor 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 in addition 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 really imposing the containment? Do we’d like a powerful comprise? I don’t assume so?

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

<fantasai>: “contain-all”

emilio: Yeah, like sth to comprise every thing 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 issues or questions?

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

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 types as a substitute of as a snapshot. Proper now, view transitions work by taking a snapshot of the “outdated” view and transitioning to the “new” web page. Nevertheless, not every thing is baked into the snapshot; some related properties are saved to allow them to be animated extra rigorously.

From the spec:

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

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

noamr: Greatest concern we need to talk about in the present day, how we seize and show nested parts but additionally applies to non-nested view transition components derived from the nested dialog. After we nest teams, some CSS properties that have been beforehand not that essential to seize at the moment are essential as a result of in any other case it seems to be damaged. Two teams: tree results like opacity, masks, clip-path, filters, perspective, these apply to total tree; borders and border-radius as a result of after getting 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 every thing by default and don’t simply seize snapshot however add extra issues that get captured as ?? as a substitute of a flat snapshot (opacity, filter, remodel, bg borders). Will change issues as a result of these types are a part of the group however have modified issues earlier than (however that is completely different because it adjustments observable computed model)
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 incorporates different teams once 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 folks need the outdated crossfade conduct they will at all times achieve this by common DOM nesting

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

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

In fact, altering how view transitions work is a dilemma to actually take into consideration:

noamr: There may be some sentiment to 1 however I really feel folks want to consider this extra?

astearns: May resolve on choice 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. Can be resolving one 1 except it’s not potential. I’d reasonably not outline a brand new seize mode with out a swap

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

khush: After we prototype we’ll discover edge circumstances. We are going to take these again to the WG in that case. Need to get this proper

noamr: It includes loads 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 loads 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 adjustments wanted if there are compat issues