Lea: this is substantial. Defer to the f2f?

Dan: I set it for next week.

brief discussions

Lea: totally new thing... Work happened to improve it. Looked at explainer - well written - we need to go through it.

Peter: I had a brief look.

Tess: also a thing where there have been lots of attempts in the broader space... to what extent are people aware of this familar with those prior attempts...?

put on the agenda for next week

Peter: homework assignment to read through the explainer.

...reviewing explainer...

Dan: is this designed in the right way to enable the UX they want to enable. Inevitably we'll have to get into the question of could there be leakage between two different documents in a way that violates privacy or breaks web security.

Dan: noting that this is purely for same-origin transitions and that cross-origin transitions aren't part of the proposal; additionally there are some noted security considerations.

Dan: reviewing the s&p questionnaire responses; looks good as long as it's confined to same origin. Cross-origin will be trickier and will require more thought. We should note that in the review response.

Dan: note other things to take into account if it was cross-origin, so we should note our response is purely in the context of same-origin

Lea: from an API point of view, do you understand how to use it? as an author?

Peter: I don't entirely follow the design

Lea: it's a very thoroughly written explainer... but I don't get it.

Hadley: doesn't have use cases from a user flow perspective

Lea: I think there are many use cases, but I don't understand how to use this to get them to work

Rossen: if you look at the default setup and how it's used in the customisation of an animation I think it's pretty easy to follow. You set up your animation as a property bag that you transition through, then execute it in the context of the new document. Querstion - if you have a log running animation, not sure what type of effect would that have? Your property value is going to be kept alive for the duration fo that animation, as stated in the section for ending the transition. Other than that it sems straightforwad.

Lea: how low level is it? Right now with CSS transitions and animations it's a significant problem that authors cannot animnate between auto and other numbers. If a container has auto dimensions in both documents can you still animate between them?

Rossen: nothing changing on the basis of this of what values are animateable. Exactly the same behaviour as any other in-page animation or transition. Intent is not to extend that. That is one of the non-goals. Not precluding that in the future.

Lea: if you use this by default you get a crossfade, and everything else is a customisation from there? That's cool.

Dan: Hadley, you mentioned you didn't think there's enough initial discussion of use cases?

Hadley: I understood they're trying to make transitions more seamless?

Rossen: the use cases are well articulated. Preamble.. different design language currently being useed in native platforms and how they benefit native applications in their transitions

... author of one page wants to fade their content out... keeping the load going in the new destination and then can kick off the animation and give you a nice transition.

Hadley: that's helpful - addresses my concerns...

Lea: if you're using an app on a phone for ex, you get these transitions - but you don't get these on the web in multi-page web applications so this can bridge that gap...

Dan: or people are forced to create SPAs in order to achieve this effect. Ideally they'd be multi-page, which would fit bitter with web architecture. Individually addressable pages. One thing that aids my understanding of it is that it's sprinkled with videos and images which help to reinforce what they're talking about

Lea: still some questions- the explainer mentions you use a prepare() method with a callback. In the example it updates the dom somehow.

Rossen: This is the time when you have the ability to handshake between the two states - and add additional state into your new environment. What they're doing: they are highlighting the fact you can use the same for both - for in-pave and between-page? Happy to look further.

Dan: I'm generally concerned about complexity, although maybe this is inevitable

Lea: I don't know..

Rossen: every time you try to create a pattern that's intended to transfer a state from one navigation to another - privacy securty, etc... - and make it execute into that new context you're going to have a set of complexity... Is it the simplest way of doing it? Not sure. On the surface when I read the explainer it didn't seem overly complex compared to the goals they're trying to achive.

Lea: if we feel it would be useful Jake could join a call...

Rossen: ...could be helpful...

Lea: hesitant to say let's move forward because I don't feel I understand it well enough. But also the use cases are very important and need solving.

Rossen: We want to do a good job of proving good reviews.... We could say we had a good initial discussion where we validated the use cases but for examople I haven't validated what it means for accessibility - certain live regions on the new document that may be covered with other content. Other one is the privacy - which is mitigated by it being same origin. Next logical step is how do we make it work for cross origin. Don't want it to be carried forward to cross-origin. They already have some experimental implementation. My suggestion would be to load up one of their examples and get a feel for it.

Dan: Agree with Rossen. I don't think we need to bring Jake onto a call given our schedule. We should be able to accomplish some additional work with him or the requestors async. Would it be possible Lea to leave some comments on the thread asking the questions that you have? One thing that does strike me [... misse d a bit...] there's some more example text in the spec, but it's not exactly what I'm talking about, maybe that doesn't exist

Peter: I remember a tweet from Jake linking to some demos, but can't find it

Dan: we could ask him

Peter: I know he has these resources. He can probably link us.

Lea: Might be easier to wrap our heads around it if we have a presentation

Hadley: separate call?

Dan: let's ask some questions, then decide if we want to bring someone in

Lea: there are code samples without visuals.. I'm having trouble connecting code samples with the output

Dan: yes

Lea: some are more clear. The customisation of animations section is the most clear one. That is what got me to understand. But animating width and height shows a nice animation. What is the code that produces that animation? How do you get that kind of effect? I don't understand.

Rossen: transition both the width and height properties into 100%

Lea: that is not the only thing that is happening there

Dan: under that one there's a link that says this is relatively easy...

Lea: [clicks link]. Before formulating questions I need to spend more time in case there are links with answers.. I want to respect the time they spent writing that.

Dan: there's a lot of links to a chrome developer document from about a year ago which ... should be in the explainer

Lea: I can ask about examples more tied to animations

Peter: let's just ask Jake if he has more concise code, then look at that then decide. Agree with Lea, obviously a lot of effort went in. But as I go through this there's a lot of handwaving and presumptions of knowledge which is not necessarily clearly laid out in the explainer. Big chunks I'm missing. Not seeing.. to me a lot of the design of this feels weird. I accept that it's probably necessary, but why the design turned out this way and the reasons is not explained either

Lea: yeah, there must be something we're missing..

Peter: some shared knowledge that is not being expressed

Dan: maybe we need to ask them to write down more explicitly use cases.. they are expressing use cases, but I'm not sure.. sentence about ...

Rossen: what if you ask Jake to provide .. to pick any two examples and provide the end to end code.

Dan: noting jake responded to Lea's comment. Great!

Peter: I have some other concerns on the CSS side of this - will dig into it and formulate my thoughts... structure of pseudo-elements feels weird to me... Let's bump to next week.

punt to plenary

Lea left comment asking if the TPAC session was recorded.

Peter: some activity in CSS about this having to do with pseudo-elements. Has the explainer been updated to reflect those changes?

Dan: there has been some pushback on our points but do we care enough?

Lea: this seems too complex.

Peter: i feel the same way - too complicated and bolted onto the side... Also this is a complicated problem to solve so this may be the best solution.

Lea: kind of inclined to say "OK" ...

Peter: i feel like i need to play with it to better understand it.

Lea: they want to push it forward...

Lea: the concerns are about complexity...

Peter: if we just say "yes we have concerns we think this is too complex" i don't think that will cause them to step back and revisit their design. My concern is : is this the right approach? I hate to give them that feedback without understanding a better way to do this.

Dan: can we couch it in terms of developer ergonomics. something about layering?

Peter: if we can't easily wrap our head around it... Authors should get some high level thing that they can just use... I'd like to see that.

Dan: can we leave feedback ....

Lea: there's an experimental implementation in chrome...

Dan: have developers been using it?

Lea: that would be great...

Dan: something like:

Do you have any feedback from the current exerpiemntal implementation that could help to answer this question?

Is the implementation up to date with the current syntax?

@jakearchibald

We looked at this again today and had some questions:

• Is the current experimental implementation in Chrome up to date with the current syntax?
• Do you have feedback from authors that have used the experimental implementation? Have you observed any of them using it and seen what they struggle with?

We are particularly concerned about the complexity and ergonomics of this API, and we (TAG members) have not yet had the a-ha moment where we fully understand how all the pieces come together to create a transition in a real use case from scratch. Given the trouble we've had with it, that gives us some pause about DX in the wild. Perhaps it's an inherently complicated problem and there cannot possibly be a simpler solution, but it is a concern that came up several times in our discussions.

Regarding https://github.com/w3ctag/design-reviews/issues/748#issuecomment-1225922770 , the main issue I see is that with the current API, updateTheDomSomehow() needs to be repeated twice, which is fine when it's a separate function, but it means all such DOM modifications need to become separate functions, which as an author I'd find annoying.

lea to leave comment

bumped to plenary

Lea: we talked aout developer complexity -- jake wants to have a call - we haven't scheduled it yet.

dan reschedules for week of jan-9 and Lea will try to set up call with Jake before then

Lea: I had a call with Jake Archibald - we went through some demos - it's more clear to me how this API works... My concerns were - there's a lot that has to be done with JS. There's a declarative version - same API for multip page and single page apps. For SPA it requires JS. For MP there's a declarative version. A way to solve the declarative problem... use JS for the transition as well..(?) Transition itself is specified in CSS. View transition name needs to be unique... Failure mode inconsistent with web platform... No way to specify if you want a different transition depending on pages or elements... unless you hack together with more JS. Biggest take-away: I do think it's usable as is. I would like simple cases to be possible to do declaratively. You still do some wrangling with JS. Say you're animating from a list of things with images to a full page showing the image. The way you use the API - you add a class to the thing you clicked and then remove that class and add it elsewhere... Still more simple than with CSS, where you have to wrangle a lot more things...

... You can enable flags in Chrome Canary... if you want to play with it...

deep thought ensues

Peter: where do we go?

Lea: Satisfied with concerns? There is a strong user need. As long as you're willing to write JS it's OK. my main concern is you have to write JS in some cases where you don't have to otherwise. Other concern: you must [...] the DOM manipulation (in SP version) ... if you want to add a transition you depend on the library firing the right event...

Peter: how would you do it declaratively? If you're going to wind up making changes to the DOM.

Lea: when you click an element and it gives you more detail - how do you declare which element is the staring one since CSS doesn't give you a mechanism for that? It would be nice if there was a way to say. Since the browser knows when the DOM has been manipulated.

Peter: my concern: is there anything about the design that preculdes declarative - probably not. The point about not being able to have different transitions depending on what the elements are is concerning.

Lea: also what the pages are in multi-page. Transitions are supposed to communicate meaning, not be only decorative. If it doesn't matter where you're coming from and going, they are just decorative.

Peter: should be addressed in future.

Lea: it could be worked around...

Peter: give feedback to ask if they've thought about that... Let's not paint ourselves into a box... with an API design that makes it difficult to add later.

Lea: I can give that feedback.

Rossen: I have thoughts.

Lea: my questions were answered today... They are already thinking about transitions dependant on elements

Rossen: so not precluded by the current design?

Lea: Correct. Concern about.. if you use a view transition name that is a duplicate you get a warning, is that consistent with the rest of the web platform?

Peter: if it just goes and spits out a warning that seems odd

Lea: you lose the transition altogether, and it spits out a warning

Rossen: you can't even handle it easily?

Lea: you can't because its CSS.

Peter: is the case where you have multiple things with the same name.. in CSS specificity wins

Lea: right, in most things in CSS. With this new css property that's not how it works. If you have a duplicate view transition name.. if you specify the same view transition name on two elements - and the way css selectors work makes this very easy - you're supposed to manually make sure you only apply this to one element in the entire tree. If you have duplicate ones, no transition happens, you just get a warning. The reasoning being maybe in the future they might want to do something clever with multiple elements that have the same view transition name. So that might make it easier. Seems to me CSS printing out a warning is nto very consistent. We even have a principle about declarative syntax shouldn't throw warnings somewhere, at least to html. Maybe should expand to CSS.

Peter: the issue is when you have the same transition declared for multiple elements? Not multiple transitions with the same name?

Lea: you use the same transition name on the start and end state,s which could be different or same elements. Same property with an identifier. If you use that on multiple elements at the same time that is a problem. When you use it to specify the start and end state you're supposed to add the name on the starting element and at some point you move it to the end state element. Unclear to me at what point that happens.

Peter: warning if multiple elements have the view transition name at the same time?

Lea: yes. Then you don't get a transition at all.

Peter: does seem weird

Lea: I wonder if a better design might be to explicitly say what is the start and end state, instead of a property that does both at once. But haven't thought about it as much as they have, maybe there's a reason not to do it that way.

Peter: could ask

Rossen: and ask if using root as the name would ever work? If you look at the clarification they have about using the view transition name custom ident it's defined as the element can participate.. as either a node or new element with view transition name equal to custom ident value.. [reads] ... so now if I go and add a transition called root, what happens? Do I get a warning and the document elements one doesn't work?

Lea: [will ask]

@jakearchibald and I had a call about this yesterday, and I think I now understand how this works and how the different pieces come together a lot better. We later discussed this again with other TAG members in a breakout.

We are aware that you have all been thinking about this for a lot longer than we have, and it's entirely possible that you've already explored all this and concluded the current API shape is a necessary compromise, but in case it helps, these were our thoughts:

• We like that MPA transitions are declarative, and would love to see a declarative syntax for SPA transitions too, as right now the two APIs feel a bit disconnected. It's also an antipattern if an author needs to write JS to animate a DOM manipulation or navigation that was not fired through JS. A declarative way to transition hash navigations within the same document could address some of that. Perhaps also a declarative way to filter view transitions by container and types of DOM mutations? This would also facilitate enhancing behavior from third party scripts with view transitions, as these often use their own events, which makes it hard to time the JS call.
• It looks like CSS would be a more appropriate place for the declarative opt-in, rather than an HTML <meta> element which cannot be customized by media queries or scoped to elements in the future.
• We think it's essential to be able to customize the transition easily based on the elements or pages that are participating in it. Good transitions communicate, they are not just decorative. If the API makes it simple to have the same transition regardless of what is transitioning to what, but tricky to customize it, it facilitates transitions which are merely decorative.
• We think that skipping the transition and showing a warning when there is a duplicate view-transition-name is not Web Platform compatible. Typically in the declarative languages of the Web Platform, when something needs to be unique but isn't, is still handled gracefully (e.g. by using the first or the last one). Especially this being a CSS property, it's very easy to accidentally specify it on multiple elements, simply because it's very easy to specify selectors that match multiple elements. Also, since the root has view-transition-name: root anyway, how do you use that without having duplicate transition names?

We wondered if it could prevent some of these issues and allow more room for future expansion if view-transition-name distinguished between the start and end state (e.g. through old and new keywords, possibly used together if the same element is both). That also prevents the user having to time when view-transition-name: foo will be removed from the start state and added to the end state: both can happen at once, at the same time as the event that kicks off the transition.

In general, we'd like to see a layered, gradual approach, where a small amount of declarative CSS syntax can address common use cases, more CSS can customize the transitions further, and JS is needed to customize behavior even further than that. This is also in line with how existing CSS transitions and animations work, where syntax is gradually added to customize further, but very little syntax is needed to produce an initial result.

We also think tighter collaboration between the designers of this API and the CSS WG could help address some of these issues.

Lea: long thread... I had a breakout with Jake Archibald. Still had some concerns that I outlined in a comment. Had a response but not fully digested.

Lea: at this point we're going into the weeds. We've gone back and forth extensively.

Dan: have they been responsive to our feedback?

Lea: Yes.

Dan: Maybe it is a good point to close and ask them to keep us updated. We've already raised complexity concern. "We are particularly concerned about the complexity and ergonomics of this API." Can we give them a challenge to work to explain this API to developers, especially considering the complexity factor?

Lea: I don't think the problem is documentaiton. I think the explainer makes a lot of sense. I think the explainer does a good job of explaining how the API works. The latest feedback on jan 10 was about other issues.

Lea: i'm thinking we should say "we have some concerns - we like overall that you've been working on this - thank you for being receptive to our feecback - please keep us updated."

Dan: agree. What's the issue outcome? "with concerns"?

Lea: the fact that you have to write js for things that don't otherwise require js is an antipattern. That you can't write transitions fo rthings triggered by 3p libarries you're not controlling. Fairly complex to hook into that. Wrap the entire transition into a callback. also understand the rationale, but it's a concern. Would like them to look at our feedback and try to address it - I think they are doing that, trying to think about it and filing issues.

Peter: agree "satisfied with concerns". Looks like there is work to do and it is being done