Matthew is not present, so we decided to pass on this one.

• [we discussed in breakout A and feel we can close as satisfied. See discussion in breakout A minutes. - DKA]

Seems fine to Matrin and Peter

Matthew: APA has a liaison with CSS, who has been following this. CSS WG knows their stuff wrt to a11y. Aware of concerns, so no cocnerns from that perspective. Architectural, cross enging stuff - no position from anyone but chromium, but is documented in fpwd so the group must have consensus. Trying to find where we'd discussed it before... would be nice to see authoring advice from an a11y perspective in the document. Common for there to be an a11y considerations section, but probably some stuff specific to view transitions that might be suitable for one of those documents. Finding the right place for that if it's not there could be an APA thing.

... Wider issue that I don't think blocks this - increasing talk about people who are sensitive to motion, potentially with health implications, or a cognitive load thing. We have prefers reduced motion, but we don't have prefers no motion - and even if we do, what about animated gifs, js animations etc. There's a platform issue there that hasn't been addressed fully that is in the background (not specific to this design review).

... APA will just keep following and offer authoring advice if we see an opportunity to do that.

Dan: close satisfied?

Matthew: yes. Could check my assumption that there is consensus in the group?

Yves: quite common to be missing feedback in standards positions, for various reasons

Dan: we could note here that we're thinking about closing satisfied and we can check in with rest of TAG for more information later this week

Matthew: we discussed last week - there have been no objections to closing it as satisfied.

Matthew: from an a11y perspective, aware of the work on this - all being done with accessibility in mind and not breaking it...

Dan: there is multi-implementer support - at least from webkit.

out of band, recording Martin's +1 to closing this as satisfied

re-opening discussion with Lea present

Lea: It seems like an incremental feature on top of an existing API...

The explainer mentions the use of classes as a considered alternative that was rejected. This does not seem very convincing.

There's a way of conceiving this problem that looks somewhat different to what is described. Think of ::view-transition-group as a way of selecting elements by their name (like div or p, not an assigned name). That is too imprecise in general. There might be many div elements on a page and you don't want to animate all of them. So view-transition-name is a way to assign a name to elements that overrides its natural name.

Similarly, you could use classes (as in <code><div class="foo"></code>) here. We aren't convinced that an override for classes is necessary. The example in the explainer uses:

.list-item { view-transition-class: vt-list-item; }

In that model, ::view-transition-group() contains an ordinary selector that applies to both new and old trees. You can (and probably should) use view-transition-name to pick specific elements for transitions if you are using element selectors. But you could also use ::view-transtion-group(.list-item), ::view-transtion-group(#foo) (ignoring that the combined new and old trees will have duplicates), or ::view-transition-group(h1 + p:first-letter) (even if this is not a great example).

That is, just use regular selectors. People who need new labels because existing classes don't align with their view transition needs can add new classes. There is precedent for using selectors that way (as a pseudo argument), e.g., ::slotted() and :host().

Maybe the feature here is a different one entirely. In CSS, you often have a bunch of selectors that receive the same rule:

.list-item, #foo, h1+p:first-letter { some-rule: 42px; }

This feature is adding a way to replace that list of selectors with a new class, like so:

.list-item, #foo, h1+p:first-letter { extra-class: shortcut; }
.shortcut { some-rule: 42px; }

Which is a novel feature, but maybe not one that is necessary. The second example there is simply more verbose and maybe use of :is and nesting is sufficient for most use cases.

Matthew: Seems like Peter has seen it and doesn't have objections... Tess said "it’s a weird layering violation if the spec mandates the use of a specific class name"... Lea said *There is precedent for using classes that way (as a pseudo argument), e.g. ::slotted(), :host() etc. * ... sounds like there is a bit of concern from the chat..

Matthew: it seems several have come out with soem minor to moderate concerns ...

Dan: let's punt this to C where both Tess and Martin will be present.

Matthew: in a recent breakout, we agreed that it makes sense for APA to file a comment to ask how media queries such as prefers-reduced-motion (and contrast) would be handled across documents, where one document responds to the query and the other doesn't... and potentially ask for a clarifying note ... Not really architectural level feedback. There was a thread in slack where TAG were talking about parallel classes... but didn't sound like a show-stopper.

Dan: anything in our conversations mean we should not have a resolution:satisfied result?

agree to bump to C to see if we can collect Martin's thoughts

Matthew: we need to decide if we're OK with closing it... Nobody has said "this is bad"...

Peter: if you're designing a transition that you're expecting multiple pages to use that transition... so that's an argument for it. But is having this layer of indirection useful?

Thanks for bearing with us. After reviewing and discussing internally, we have one question which is: did you discuss the option of using selectors and if so could you document in the explainer the reasoning for not using that approach?

We see the extra layer of indirection as being useful if view transitions can be used with multiple arbitrary pages, but it's unclear if the transitions will be generic enough in general to be reused. If the transitions need to be tailored to the specific page content then an extra layer of indirection doesn't seem useful.

comment left https://github.com/w3ctag/design-reviews/issues/938#issuecomment-2269500378

Matthew: some discussion...

Peter: this doesn't make sense to me... seems one way or the other you've got to cache what things .. apply to. I'll make a comment ... asking that.

Matthew: If we have to have something else other than just a selector, why don't we call it something other than viewtransitionclass - like viewtransitionname - not using the word class.

Peter: I agree - using class is confusing ...

Dan: Support.

peter leaves a comment

Matthew: I do understand that this is a separate concept to viewtransition name... they are trying to do the same thing with css classes and used the same name. that's why they've used the same name... BUT they aren't classes... I appreciate why they want a way to indicate it syntactically... and classes in a concept of CSS is doing the same sort of thing. But this isn't a CSS class so it's tricky. I think this could be a "foot gun" for DX.

Peter: yes I think they are re-using the concept of class... But it's not a class. I don't think they should use the . syntax... If that pseudo-element took a name... but I don't think it does. So no reason for the ..

Matthew: i think you can do view transition group...

Peter: if that's the case then they do have to distinguish...

Matthew: according to the explainer - the needed a higher level thing so decided to do "class"...

Peter: in that design, the . makes sense...

Matthew: they address by saying "there is an *"...

Peter: don't need a *... but they say in the background... 1-7... why can't it just be "list item 1, list item 2, " etc...

Matthew: shall we ask them?

Peter: posts comment

Matthew: +1

bumped

Jeffrey: we will discuss at TPAC (lots of time zones to coordinate on this one; Lea and Peter have reservations)

Yesterday's breakout thought this could be closed, but needed to go through Peter first.

Peter: I had more thoughts that I wanted to throw into the issue, so I'd like some more time.

Peter: They're associating things with content, but CSS already has selectors for that. Using the same name for different concepts is concerning. Have to assign the names with selectors anyway, so why aren't we using selectors? If we need indirection, there are other ways we do that in CSS. Don't see the need.

Jeffrey: Has this gone through the CSSWG?

Peter: Think so, but I haven't been following there. My read on this seems to be so they can capture what transitions apply when content go away. But I think that's an implementation detail. There's a problem that the content's gone so selectors won't match. But the content's gone, so the associating selectors won't match either. So you had to capture them somehow; use that again.

Peter: Also concerned about how they're using a pseudo-element tree to define the transition. But that's completely separate from this issue.

Martin: I share the concerns about the indirection layers. Noam points out that we need some sort of indirection thing to avoid error-prone cases. Using a class at a layer down doesn't help. Building a document tree before and after. Need to say which things are the "same", and apply a transition. Selecting those things is currently new identifiers, but applied using selectors. So just use selectors. The work will be in articulating that more clearly.

Jeffrey: Should we invite the proponents to this breakout? [No, Noam's in Europe; Breakout B.]

Peter: CSS also has some techniques for grids, which we could re-use.

Martin: Find some time at TPAC?

Jeffrey: I'll raise that with the proponents.

we need Peter

Dan: let's revist at plenary.

Peter will talk with Noam or do a writeup to clarify the disconnect about use of selectors.

Punting that. Call on Monday.

[with special guests]

Peter: view transition classes... some disconnect... mechanism for adding classes... seems to be recreating what selectors is doing... Taking a view transition and binding it to an element... that's what selectors do... So I don't see the point of it...

Vladimir: our model is not so much that it binds ... but uses element info to create a new pseudo tree... configures the pseudo-tree to act like... Regular slectors would targer the dom...

Peter: I don't quite fully get the point of the pseudo-elemnt tree... fundamentally the notion is ...

Noam: the whole concept of view transitions is .. when the transition happens, the dom that generated it is no longer applied... it creates a snapshot... all those things can be changed... the only thing that's left is the transition itself .. it's outside - a child of HTML - the only thing that exists there is pseudo-elements and their names... Separating it from topology of the dom allows for flexibility... Dom is rigid... One of the problems we have is .. when using unique name for everything you have to do a lot of repetition... Every element that is being animated you need to give it a unique name. So we wanted to style many at a time.

Peter: similar things like grid lines... why do the names for view transition elements need to be unique?

Noam: this was an alternative that was discussed... It was copied from known idiom from the web... also the unque name is how to grab ele,ment

Vladimir: the uniqueness point - it maps one element on the old dom state to an element in the new dom state... so it can't be reused - it's an ID in the page.

Noam: I see how it creates a weird thing... it's an underworld that copies the real world ... I see it as a feature...

Peter: to me - the problem is that re-using the concept of classes... it generates confusion for authors... sort of like classes, but not classes, but uses the class syntax...

Dan: developer complexity blah blah

Jeffrey: I wonder if the thing to do here is to ask the CSS wg to look at this issue again... and schedule some time where Peter and Martin could come to ... and discuss further...?

Peter: certainly a possibility...

Matthew: i can understand the desire ... I'm wondering: when the name viewtransitionclasses was developed were there alternative proposals?

Noam: yes - this duplicates the discussion in the CSS wg... all of this is in the minutes... hesitant to repeat without new information?

noam to send link to this minutes

Noam: a few names were suggested ... [this was all discussed in CSS]... I think it's 90% like classes... regular dom tree provides the names and classes... regular css tree provides names and classes for view transition tree. something less complex about this then inventing new names...

Matthew: I think this was the link given re the prior discussion: https://github.com/w3c/csswg-drafts/issues/8319

Vladimir: ... there is a desire to target "not one but not everything" - which is the function classes play in regular HTML... which is why we ...

Lea: also querying about selectors

Lea: there's 2 states - what's there when you start and when they finish ... couldn't you set a class on an ancestor?

Noam: with cross-page the new stare is what decides on things...

Lea: ... you could do the same thing with selectors...

more discussion on selectors

Lea: the pseudo-element is on something...

Vladimir: not clear to me what the proposal to target multiple...

Noam: you could implement a subset of this feature with [hostcontext]? You would probably be able to have some aspects of the feature but not everything - you'd lose exit transitions...

Lea: targeting elements based on a property ... has come up multiple times .. perhaps there is something that can benefit all of CSS ... concerned about introducing something that's different to other ways CSS works...

Vladimir: this property effects how pseudotrees are constructed...

Lea: looking at these code examples, I'm worried about the DX... everything under a selector would have a certain view transition class..

Vladimir: on the exit transitions it would need to preserve that topology... we are currently just naming it... whatever it was, give it a name... what you're proposing you would need to remember ...

Jeffrey: so where do we go from here... CSS wg would need to agree.. seems like we should be trying to continue...

Noam: there has to be a counter proposal to CSS to bring it up in the wg again... or an enhancement...

Lea: if something like this design goes forward could we make it less like class... to make it clear this is a custom thing... similar to animations, font palette.. Similarly if the naming cannot used class ... that might be more consistent..

Peter: Lea mentioned .. the problem here is that classes themselves are assigned by selectors... when old DOM goes away you have to have memorized those classes.. if you're doing that why can't you just have used regular selectors to target the transitions and then captured that at the same time?

Vladimir: the answer is... what you're proposing is - at the time of targeting, remember a particular selector... not clear what the selector is ... right now our answer is "give that whole thing a name"...

Lea: you could argue that the selector matches the end state... but sometimes needs to match the begin state. CSS is a reactive language. This introduces an ordering effect...

Vladimir: in terms of reopening ... right now the state of the world is that as far as CSS wg is concerned this is added... so to re-litigate it would need to be opened as an issue?

Peter: i'm not opposed... I think where it landed is not idea... i think it creates developer confusion... i think it would be good to see if there is a better answer. Allowing multiple names; capturing information; etc... also I accept there's something I don't fully grok. We should push back from the TAG to the CSS wg on developer confusion issue...

Dan: who's getting what on the CSS agenda?

no action thus-far

Jeffrey: they are doing a breakout for some view transitions issues next week [?] if we want to be engaged that's a good time to engage.

Lea: either October 30th or nov 6, but doesn't look like it's decided.

Jeffrey: should we close our issues as satisfied-with-concerns?

Peter: don't feel like we're satisfied?

Lea: if we're satisfied with the use case and not the solution then it's not satisfied.

Dan: so who's gonna do what?

Lea: maybe someone who is not part of CSS wg should post? I can write it though... Let's summarize our concerns:

Dan: Key point I was hearing was developer confusion arising for the overloading of the term "Class" in the CSS context.

Lea: if they don't use the class syntax and they don't call it class, then are we OK with it?

Peter: i'm ok-ish. The conflation with class is my primary concern... but also concerned with using something like class ... where there could be competivie solutions. One of the solitions we discussed briefly on the call would be allow multiple names...

Matthew: from minutes from last week - https://github.com/w3c/csswg-drafts/issues/8319 - where they told us it had already been discussed.

Lea: looking at that thread, I think Peter suggested repetitive code... he reasonably suggested why can't authors use selectors .. answer was that selector isn't valid at that time. But could this be an internal implementation detail... What if it's the browser generating these rules? Then the experience for authors is just specifying selectors.

Jeffrey: I think we need someone to write that down...

Draft proposal:

Summary of feedback, following our discussion on last week's TAG breakout call:

• If you're really set for this:
  • don't use syntax around classes
  • support multiple comma-separated arguments to improve ergonomics
• We'd prefer to eliminate the repetition in the first place, e.g. by having the UA generate these rules as an implementation detail

we agree on above, Lea to augment and post both to CSSwg and our issue