Proposal: shared element transitions

[chrishtr]

Shared element transitions is a proposal for a new API that allows for transition animations when navigating between different application views, for both Single-Page Applications (SPAs) and Multi-Page Applications (MPAs) .

See the link above for a lot more details, plus various issues discussing different use cases and aspects of the current
prototype spec and implementation. I'd like to emphasize that this is just a prototype built to gather feedback, not a proposed thing to ship as-is.

We'd like to discuss the use cases this API is aimed to solved, plus share our findings so far from prototyping, with the CSSWG, and gather feedback.

@khushalsagar @jakearchibald @ianvollick @vmpstr

[css-meeting-bot]

The CSS Working Group just discussed Shared Element Transitions.

The full IRC log of that discussion

<TabAtkins> Topic: Shared Element Transitions
<TabAtkins> github: https://github.com//issues/6464
<TabAtkins> JakeA: [slides]
<TabAtkins> JakeA: I'm helping out with this Shared Element Transitions work, along with Jeremy and Khushal
<TabAtkins> JakeA: Current state: when you navigate on the web, the page just changes
<TabAtkins> JakeA: but on apps, especially in mobile, you get these lovely transitions betweens tates
<fantasai> [slide shows various transitions, like sliding in a sidebar, swiping across panels, etc]
<TabAtkins> JakeA: they look nice in person, and can even be directly useful, to help communicate transitions between states so there's less context loss
<TabAtkins> JakeA: I asked people on twitter about this, especially if they'd like it in a SPA or MPA (multi-page app)
<TabAtkins> JakeA: most people were interested in it for a multi-page app!
<fantasai> [slide shows Twitter survey of SPA vs MPA, 31% to 52.9%]
<TabAtkins> JakeA: I see why - you can already kinda do it in a SPA, but it's impossible in an MPA
<TabAtkins> JakeA: Strong feeling that manys ites *become* SPAs just to get these transitions; not sure, but it feels like it.
<fantasai> s/manys ites/many sites/
<TabAtkins> JakeA: And that's a problem, SPAs have a lot of issues, and they're often done badly.
<TabAtkins> JakeA: But even when done by experts, you lose things like HTTP streaming, gain a big JS bundle, etc.
<TabAtkins> JakeA: So thinking about this space
<fantasai> [slide shows timeline]
<fantasai> [2015: Chrome proposal and experiment]
<TabAtkins> JakeA: 2015 was an early chrome proposal, didn't go very far, and the people left for other projects
<fantasai> [2015: Chris Lord (Mozilla)'s sketch]
<fantasai> [2017: Jake's sketch]
<fantasai> [2018: Tab's sketch]
<TabAtkins> JakeA: 2017, I sketched an API. Each time we learned more things that might work.
<fantasai> [2021: This round!]
<TabAtkins> JakeA: 2018, Tab had his own proposal
<TabAtkins> JakeA: And now we're here today
<TabAtkins> JakeA: Not the first people to even try this out, back in '97 IE had something.
<fantasai> [1997: IE4 with navigation transitions via meta http-equiv="page-enter"]
<TabAtkins> JakeA: 24 years ago, you could use <meta> to do page transitions
<TabAtkins> JakeA: there were 22 transitions to choose from; several dupes from different directions, like "wipe left" and "wipe up"
<fantasai> [ <meta http-equiv=page-enter content="RevealTrans(Duration=0.600, Transition=6)]"> ]
<TabAtkins> JakeA: also a special 23rd transition that made a random choice
<TabAtkins> JakeA: slightly kidding, but I think a predefined set of transitions can get us pretty far
<TabAtkins> JakeA: But not all the way, I got feedback from people asking for custom control
<TabAtkins> JakeA: If we look at some of the nicest transitions in the android docs
<TabAtkins> JakeA: It's animating between states in multiple ways; some things are shared between the states
<fantasai> [shows Android Contacts list, clicking on name of person shifts the name up and colors/layout changes to show a profile]
<TabAtkins> JakeA: This person's name in the address list moves to be the header for their profile
<fantasai> [Jake's homepage with 2-line title vs 3-line title]
<TabAtkins> JakeA: on my blog, when you're on the index page and click thru to an individual post, the headers are basically the same. why coudln't that transition?
<TabAtkins> JakeA: Every element on the two pages are different, even different tag names.
<TabAtkins> JakeA: Some elements change content, some elements (dates) don't change content but do change position.
<TabAtkins> JakeA: Header changes layout, it does a fade to the new larger text
<TabAtkins> JakeA: and header container scales its height
<TabAtkins> JakeA: then the rest of the page just fades content
<TabAtkins> JakeA: There was a bunch of moving parts here, but overall, it was simple because it was done with just textures, no live layout between the two
<TabAtkins> JakeA: So didn't need to keep the old page alive
<TabAtkins> JakeA: there are some concepts we keep coming back to
<astearns> https://github.com/WICG/shared-element-transitions
<fantasai> [slide: Change]
<TabAtkins> JakeA: First, there's a change
<TabAtkins> JakeA: Before that, we need a prepare step
<fantasai> [slide: Prepare, Change]
<TabAtkins> JakeA: where the outgoing page offers up parts of itself to be involved in the transition
<TabAtkins> JakeA: Like my blog example, offering the header, the date, the sidebar
<fantasai> [slide: Prepare, Change, Transition]
<TabAtkins> JakeA: Then the change happens, letting the outgoing page be cleared from memory except for the textures it's offering up
<TabAtkins> JakeA: Then the Transition happens, where the new page animates in
<TabAtkins> JakeA: LIke, if you have a series of chat messages, the old page might have three messages, the new has four; the three can just fade in, but the fourth has to do something special; this is where that can happen
<TabAtkins> JakeA: Like I said, these are textures; we don't want to do layout on the old page
<TabAtkins> JakeA: But we also don't want the new page to get pixel readback from the old textures
<TabAtkins> JakeA: New page is trusting waht the old page gave it - it says "this is a heading!" and the new page trusts that it's a heading
<TabAtkins> JakeA: for cross-origin transitions that's a potential concern
<fantasai> [slide: cross-origin transitions]
<TabAtkins> JakeA: The old page could offer up bad stuff
<TabAtkins> JakeA: A bad page could transition into a news page, offering up its "header" and boom, it's the q-anon logo
<TabAtkins> JakeA: So cross-origin transitions either need to be heavily restricted
<TabAtkins> JakeA: Or need a two-way handshake to agree on which textures to share
<fantasai> [slide: single-page app transitions]
<TabAtkins> JakeA: There's also single-page app transitions
<TabAtkins> JakeA: Not as manya uthors are interested
<TabAtkins> JakeA: because they're actually quite hard to do today
<fantasai> s/manya uthors/many authors/
<TabAtkins> JakeA: You need DOM for both states at once, which means you need to protect the old stuff from being interacted with, or being seen by a11y tools
<TabAtkins> JakeA: Need to control for scroll position, how it can mess up CSS mid-transition, etc.
<TabAtkins> JakeA: Twitter says they don't do transitions precisely for these reasons
<TabAtkins> JakeA: So we were thinking about this and realized this should work on the page transitions model just as well
<fantasai> [slide: prepare, change, transition]
<TabAtkins> JakeA: You're still doing a prepare phase to record bits of the old state, then you transition into the new state
<TabAtkins> JakeA: We already ahve a sketch of the SPA model behind a flag in Canary
<TabAtkins> JakeA: Here's an example of the Preact website
<fantasai> [slide: preact website SPA]
<TabAtkins> JakeA: Author of the site says it's "a mess", but it has a router for the overall site transition as many SPAs do
<TabAtkins> JakeA: But even tho I didn't understand much, I could easily poke in and add the transitions API, and it all just works
<TabAtkins> JakeA: BAck button reverses transitions, it's all just very little code
<fantasai> [slide: preact website with subsections fading in and out in the content panel]
<TabAtkins> JakeA: In spirit, our current design is very similar to the old IE version, with a list of predefined transitions
<TabAtkins> JakeA: New bit is this "shared elements" notion, like the heading and sidebar in the guide.
<TabAtkins> JakeA: In this example I'm using this to keep them in position and only change the content by sliding it in
<florian> q?
<florian> q+
<fantasai> [slide: Interesting Problems]
<TabAtkins> JakeA: While we need the bare-bones for EWM reasons, I think there's definitely a high-level version that solves 80% of cases
<TabAtkins> JakeA: Some problems.
<fantasai> [slide: cross-fading]
<TabAtkins> JakeA: First is cross-fading. Transitions have a lot.
<TabAtkins> JakeA: Hard to do in CSS rightnow
<TabAtkins> JakeA: Especially between elements with transparency.
<TabAtkins> JakeA: Can use explicit opacity on the two states
<fantasai> [slide with .thing1 { opacity: 1 } .thing2 { opacity: 0; } ]
<TabAtkins> JakeA: here's a slide where the two are identical save for a few extra words on the second
<fantasai> [slide: cross-fade shows image, which doesn't change, fades to 50% hafway in the transition]
<TabAtkins> JakeA: Midway thru the transition the shared pixels fade a bit, ideally we could fix this
<TabAtkins> JakeA: CSS has a cross-fade(), which does the right thing
<chris> This is because the cross-fade eeds to be done in linear-light
<TabAtkins> (That's not the only reason)
<fantasai> s/eeds/needs/
<chris> so that -0.5 + 0.5 = 1.0 :)
<TabAtkins> cross-fade() also blends sizes tho
<chris> s/-0.5/0.5
<TabAtkins> JakeA: Which isn't always what we want
<fantasai> [slide: background-image: cross-fade(...); ]
<fantasai> [slide: Not quite elements, not quite images]
<TabAtkins> JakeA: We're not dealing with elements *as such*; images might b eokay since we've just got textures left over
<chris> (interested to know the other reasons)
<fantasai> s/b eokay/be okay/
<TabAtkins> JakeA: but not all an image - Some information like transforms we might want to carry over so it can animate properly
<fantasai> [slide: timings and deadlines]
<TabAtkins> JakeA: Another thing to think about is timings and deadlines
<TabAtkins> JakeA: Right now when you click to a new page, the browser shows the new page when it wants, when the data comes in
<fantasai> [slide: iWouldLIkeToDoAPageTransition(); ]
<TabAtkins> JakeA: But if the incoming page wants to control the transition, it should be able to signal for it
<TabAtkins> JakeA: But how long can we wait?
<fantasai> [slide: iWouldLikeToDoAPageTransition(); await massiveImageLoad; nowDoTHePageTransition(); ]
<TabAtkins> JakeA: How long do we wait for the "i want to handle this" signal, and how long do we wait for it to actually do the transition after it signals?
<TabAtkins> JakeA: We like progressive rendering
<TabAtkins> JakeA: Do we want to allow pages to delay until a 5MB image loads?
<TabAtkins> JakeA: They can do it today, kinda
<fantasai> [slide: Thoughts? Questions?]
<TabAtkins> JakeA: But maybe if they, say, don't do it in 5s we just do a page swap
<TabAtkins> JakeA: So, questions?
<chris> Jake Archibald 17:28 https://github.com/WICG/shared-element-transitions - repo (API design in flux) https://preact-with-nav-transitions.netlify.app/ - preact site demo
<JakeA> https://www.irccloud.com/pastebin/at0XnzDj/
<JakeA> https://github.com/WICG/shared-element-transitions - repo (API design in flux)
<JakeA> https://preact-with-nav-transitions.netlify.app/ - preact site demo
<astearns> ack florian
<TabAtkins> florian: Intriguing! Overall makes sense at a high level.
<TabAtkins> florian: Curious how much ends up being declarative vs JS, how they intertwine, I'm sure y'all are thinking of this
<TabAtkins> florian: There was also something between IE4 and modern stuff. I believe Opera experiemented around 2010
<TabAtkins> florian: They were a little like the declarative transitions, but also a concept of arranging things in space, so you could say "this page is left of that one" and it would automatically swipe over to it
<TabAtkins> florian: tied into gestures as well
<TabAtkins> florian: Wondering if there has been any thought on these lines, including tied in with the "shared elements" part
<astearns> q?
<emilio> q+
<TabAtkins> florian: This notion of arranging bits of space, I thought it was interesting
<TabAtkins> florian: Doesn't seem obvious that it doesn't fit
<TabAtkins> JakeA: Hard to talk about binary declarative vs imperative
<TabAtkins> JakeA: For some peopel it just means "JS" vs "CSS", but Web Anim - which is it?
<TabAtkins> JakeA: We almost certainly will end up with something declarative to some extent
<TabAtkins> JakeA: Lot of desire to do this animation out of the control of either page; the pages just dictate how they want it to go, but it's actually handled outside
<TabAtkins> JakeA: I did put a sketch together purely in CSS, and I think I got to 15+ properties and hadn't thought about the destination url negotiating yet...
<TabAtkins> JakeA: I anticipate the destination being done in JS at least
<TabAtkins> JakeA: And maybe there's a smaller subset that can be done in pure CSS with simple behaviors
<TabAtkins> JakeA: Before I had the ability to associate elements with some ID, and if the destination page uses the same ID they're autoamtically tied together
<TabAtkins> JakeA: In the JS API I presume it'll be similar.
<TabAtkins> JakeA: There needs to be a way to give more information - like, by default it maybe just translates, cross-fades, and scales
<TabAtkins> JakeA: But scaling isn't always what you want, as I showed in some examples
<TabAtkins> chris: if you've got two things transitioning opacity...
<TabAtkins> chris: You need something where .5 + .5 = 1. That needs linear light; images aren't linear painted, which is why there's lightening.
<fantasai> scribe+
<fantasai> TabAtkins: linear-light was one problem
<chris> agreed
<fantasai> TabAtkins: Other problem is that halfway through, two 50% things laid on top of each other means together they are only 75% opaque
<TabAtkins> flackr: Gaming has opacity saturation buffers to solve this
<TabAtkins> khushal: Yeah we foudn that, there's a blend mode that can do that
<TabAtkins> khushal: I found a webkit bug asking to expose this to mix-blend-mode
<astearns> ack emilio
<TabAtkins> emilio: so the idea is that the destination page can observe stuff about the transition, like position of old elements
<khushal> https://bugs.webkit.org/show_bug.cgi?id=142416 is a bug which talked about the blend mode that would work for this.
<TabAtkins> emilio: That seems like in conflict with the UA being able to control the transition
<astearns> q+
<khushal> q+
<TabAtkins> JakeA: we hope within the API to catch spots where, like, if an error is thrown it doesn't deadlock the transition
<TabAtkins> JakeA: With this model you can definitely delay the intro of your own page. Having the incoming page control it means you're only harming your own perf
<TabAtkins> JakeA: Question of how much we want to prevent people - they can already delay their own page arbitrarily.
<TabAtkins> JakeA: Worry about damaging legit use-cases to guard against some peopel getting it wrong
<astearns> q+ later
<astearns> q-
<TabAtkins> emilio: Main thing I'm concerned about is an animation working on a good computer, but breaking on a crappy phone
<TabAtkins> JakeA: Right, so think if the transition isn't ready within 3s we just bail, or something like that
<TabAtkins> JakeA: Like doing font-rendering intervention
<TabAtkins> emilio: I took a look at the API, which is promise based; if you bail on the transition it rejects the promise, right? If the promise rejects unexpectedly the page might still break.
<TabAtkins> emilio: This would be much simpler if the UA could decide what to render without the destination page being involved, but I understand it breaks some of the fanciness.
<TabAtkins> JakeA: I see you're looking at the GH page for the API; that's still in flux
<TabAtkins> JakeA: We're def looking at ways to mitigate these problems
<TabAtkins> JakeA: Issue on GH right now looking at moving to a JS API similar to WebLocks
<TabAtkins> JakeA: In that you provide a callback to run later that returns a promise. Errors become rejected promises instead of breaking script, so you somewhat avoid deadlock.
<astearns> ack khushal
<TabAtkins> khushal: design thing i'm thinking about, which page controls the transition. reasons for that to be diff between same-origin vs cross-origin
<TabAtkins> khushal: Incoming page controlling the transition is good bc it has info from both sides, and can make better decisions
<TabAtkins> khushal: But for cross-origin cases, we can't let the incoming page know about the outgoing page, so the outgoing page has to control the transition completely
<TabAtkins> khushal: This requires different API shapes, and it's causing some API divergence
<TabAtkins> JakeA: This is something I ran into for the CSS-only version
<TabAtkins> JakeA: If you've got a shared item in the outgoing page which doesn't have an incoming equivalent, or vice versa, it becomes hard to deal with
<TabAtkins> JakeA: It's hard in CSS to talk about an element that isn't there
<eugene> q+
<TabAtkins> JakeA: Whereas in a JS callback you can get handed five elements, and four match int he new page, and you can figure out what to do with the leftover
<chrishtr> q+
<TabAtkins> astearns: You mentioned pixel access - I assume incoming page has no pixel access at all
<TabAtkins> JakeA: correct
<flackr> q+
<florian> q?
<TabAtkins> JakeA: Probably model will be outgoing picks up an element for sharing, and a StructuredClonable of info about it, like "I'm a heading" or whatever
<TabAtkins> JakeA: But no pixel access
<TabAtkins> JakeA: Hope we can one day get to a state where we can read the pixels on a page
<florian> q+
<TabAtkins> JakeA: We have origin isolation right now, maybe some even stricter version could some day allow this
<TabAtkins> astearns: And with outgoing pages opting into data sending, for cross-origin the incoming page might need to be restricted from knowing which of its transitions actually matched. No info about which headings matched, etc, just always run them
<TabAtkins> JakeA: two angles there - don't want Page A to find info about Page B they didn't want to share
<astearns> ack astearns
<TabAtkins> JakeA: In some cases the number of chat messages can leak that
<TabAtkins> JakeA: But there's also Page A and B *wanting* to share info, but for privacy we don't want to allow them
<TabAtkins> JakeA: Not sure where the line is right now
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<TabAtkins> JakeA: Might be that cross-origin is just the IE model - a list and the whole view moves
<florian> q-
<TabAtkins> astearns: you talked about having a high-level declarative variant with less features
<TabAtkins> astearns: I hope if we get there, the high-level thing can be hooked by the low-level, so you can intervene when necessary
<fantasai> +1
<TabAtkins> JakeA: Yeah, I think CSS shorthands model is something like what we want to go for
<TabAtkins> JakeA: Can set up a "sliding" animation, and it can specify a WebAnim-like set of keyframes
<TabAtkins> JakeA: And maybe we just wrap that up in "slide-left" keyword, but with full control to do your own
<astearns> ack fantasai
<Zakim> fantasai, you wanted to mention incremental rendering
<TabAtkins> fantasai: One, incremental rendering, if you're on a slow connection you want the partial page to show up early
<TabAtkins> fantasai: dunno how that's considered right now, just want to make sure it's not forgotten
<astearns> prefers-reduced-motion would turn all of this off, presumably
<TabAtkins> fantasai: There was also a discussion about shared element transitions in Burlingame, I think, not sure if there are notes or if it was informal; think Ojan was involved
<TabAtkins> fantasai: Big point I remember there was that cross-origin ones shoudln't leak info
<TabAtkins> fantasai: Another idea was sharing a timer between the two, so outgoing and incoming pages could put things on the same timeline
<TabAtkins> fantasai: Coudln't necessarily coordinate between elements, but could at least ensure timing matched up
<TabAtkins> JakeA: For incremental loading, def one of the fundamentals I want to keep.
<TabAtkins> JakeA: Def a tension between that and page transitions
<chrishtr> q-
<TabAtkins> JakeA: Would be nice to have a way to say "don't transition until X element is around"
<TabAtkins> JakeA: Very hard to do right now, tricky with a Mutation Observer
<TabAtkins> JakeA: Might be a waitForElement() API to let you delay as little as possible
<TabAtkins> JakeA: In the blog example I want *some* of the content to be there, but don't need the whole page necessarily. Probably want a way to say I just need the top of the page, not the stuff a MB away
<TabAtkins> JakeA: Nothing concrete there yet, but it's on our minds
<TabAtkins> JakeA: I didn't know about the transitions discussion
<TabAtkins> JakeA: I'll try to find notes
<TabAtkins> JakeA: In chat Alan asked about prefers-reduced-motion
<TabAtkins> JakeA: Yeah we'd just ignore the transition in that case
<florian> q+
<TabAtkins> JakeA: Re: leaking cross-origin, absolutely a concern, need to lock down properly
<TabAtkins> JakeA: re: timeline sharing, that's similar to my previous 2017 idea
<TabAtkins> JakeA: That version required both pages to be alive at the same time
<TabAtkins> JakeA: which is an issue for low-memory devices
<TabAtkins> JakeA: Thought right now is one side controls the transition; the other side just offers things to be transitioned
<TabAtkins> khushal: interesting to think about whether incoming page *has* contextual info to control the transition or not
<TabAtkins> khushal: if you're on a news aggregator, and it wants to have a transition to links, ok. but if the user enters in the omnibox, maybe the incoming page gets control over that instead. or maybe browser-initiated just doesn't get transitions.
<TabAtkins> khushal: Also, re: same vs cross-origin
<TabAtkins> khushal: In same-origin when incoming can control, we also let it control when the transition states
<TabAtkins> khushal: and it gets all the info about the outgoing page, so it can do smart things
<TabAtkins> khushal: but in cross-origin, when the incoming page doesn't have any info but might still have useful timing info, that's a difficult question
<astearns> ack eugene
<TabAtkins> eugene: Reffing on khushal's comments, if you have cross-fade capabilities, the omnibox can do its own thing controlled by the UA
<TabAtkins> eugene: we've also got scroll-to-text capability now
<TabAtkins> eugene: and ideally whe nyou're referring to a shared element, hopefully we have a consistent way to refer to those elements
<fantasai> s/Reffing/Riffing/
<fantasai> s/whe nyou/when you/
<TabAtkins> eugene: another comment, declarative vs imperative. imperative is basically marking up a single transition, I think it falls down when you want multiple things simultaneously
<TabAtkins> s/imperative is/declarative is/
<TabAtkins> eugene: So it's important to ahve the models build on each other
<TabAtkins> eugene: Big call for extensibility, building more on top of this
<TabAtkins> eugene: Think the right model is to build on the animations ecosystem, so all the existing animations work, and users get new abilities as animations get better
<TabAtkins> JakeA: re: scroll to text, I think you can use a css selector to id the element
<TabAtkins> JakeA: that works okay for sscroll-to-text because the lifetime is relatively short
<TabAtkins> JakeA: And if the highlighting doesn't work, it's not a huge loss
<TabAtkins> JakeA: Coudl be worse on transitions
<TabAtkins> JakeA: concern I have is you're navigating around a site, and mid-article the site redeploys and the class names have changed
<TabAtkins> JakeA: So model we're using right now isn't tags or selectors, it's literally just a bunch of named element references
<TabAtkins> JakeA: {"heading": someDOMEl}
<jbroman> I think scroll-to-text uses a snippets of text rather than CSS class names to avoid this
<TabAtkins> JakeA: Might need a way to bail on transitions so if two versions of a site are totally incompatible they cna figure it out
<TabAtkins> eugene: I think if it's a problem for page transitions, it'll be more of a problem for people who save links from their search bar; "scroll to image" is just as bad
<TabAtkins> It does, yes.
<astearns> ack flackr
<TabAtkins> flackr: I assume that BF nav, we want to use the transition that you saw when you came in
<TabAtkins> flackr: Not sure how it would work with the current API
<TabAtkins> flackr: But should be some way of memorizing the transition so we can reverse it if we go back
<TabAtkins> flackr: Is that something we can do?
<TabAtkins> JakeA: Yes, and the more autoamtic we can do the better; people don't often test that
<TabAtkins> JakeA: Maybe we only do it if the page is in BFCache
<TabAtkins> JakeA: gets more complicated if you're reloading the old page as well
<TabAtkins> JeremyRoman: This is a very big rathole, but interesting
<TabAtkins> JakeA: I think limiting it to BFCache and only +1/-1 transitions is a good start
<TabAtkins> astearns: Assuming you'd like more feedback in the WICG repo?
<TabAtkins> JakeA: Yes, that's the right place for it
<TabAtkins> astearns: And we can do CSS issues when you come up with a declarative CSS version of this
<TabAtkins> JakeA: Absolutely. Thanks!
<jbroman> +1; thanks CSSWG for your time
<vollick> thanks, all!
<TabAtkins> astearns: I think it'll be great to bring the web platform back up to IE4 standards.
<TabAtkins> <br dur=10min>
<JakeA> https://github.com/WICG/app-history/
<JakeA> For the minutes: https://github.com/WICG/app-history/ provides a "navigate" event which provides a central place to hear about navigations, kinda like I was able to use on the preact site (due to its router). This means if you want to hear about navigations, you don't need to listen for all link clicks, all form submissions etc etc

[astearns]

Recording of presentation: https://www.youtube.com/watch?v=UIWZFXwAPxE

[tabatkins]

Minutes of 2021-09-02 discussion

07:07  khush: At previous session we introduct SET

07:07  khush: Goal of getting seamless transitions like native apps

07:08  https://docs.google.com/document/d/1r22ITZhL--X_KiPodv5Ju5hWaaoQSXO2xajvW7N33bQ/edit#heading=h.cl4cs2jqxgff

07:08  khush: Now we're discussing design problems

07:08  present+

07:08  khush: Hope this doc gives us starting points for discussion

07:09  khush: basic model here is that you cache some state from the old dom, and when th enew page loads you animate from that cache. "cache" is a pixel snapshot and a little metadata about sizing/positioning

07:10  khush: So is this the right idea? we want it to work for same-document transitions also

07:10  Rossen_: So what's your dfn of pixel snapshot?

07:10  q+

07:10 — Zakim sees emilio on the speaker queue

07:11  khush: We keep a copy of the texture the subtree was rastered into

07:11  JakeA: so at this point the old dom is gone - if this is cross-page we've already done 'unload' on the previous document

07:11  JakeA: it's "donated" parts of itself for the transition

07:11  JakeA: Same for same-page

07:11  JakeA: Can't lend the DOM itself across documents, that's a hard limit, so what we've landed on so far is that it's just a pixel repr

07:12  Rossen_: I can see how that can work in simple scenarios... is this pre-blend, post-blend...?

07:12  Rossen_: what exactly do you mean by "save the texture"?

07:12  khush: exactly what we need to define here

07:12  khush: "stacking context output" is probably the closest concept we have

07:12  khush: Before you apply post-effects - filter or ancestor opacity, etc

07:13  Shared Element Transitions Doc (archived): https://lists.w3.org/Archives/Public/www-archive/2021Sep/att-0001/shared-element-transitions-concepts.pdf

07:13 <Rossen_> ack emilio

07:13 — Zakim sees no one on the speaker queue

07:13  khush: if you've just done a transition to an element with changes of filter/opacity, we try to animate those nicely

07:13  emilio: How does this work with window resizes?

07:13  JakeA: window resizes during transition?

07:13  emilio: Any time after you've captured the pixels

07:14  JakeA: so we take the pixel snapshots at a phase, then some time after that the resize happens

07:14  JakeA: My assumption so far is that we'd abandon the transition

07:14  emilio: That's an option

07:14  khush: It becomes so difficult - the layout can change, but we've captured the layout in the previous layout

07:14 <Rossen_> q?

07:14 — Zakim sees no one on the speaker queue

07:14  JakeA: To be clear "abandoned" just means skip to the end, not leave the page in a broken state

07:14  flackr: Layout can change due to non-resize events too, tho, right?

07:15  khush: Right, but a resize isn't under the page's control, that's author. Other things, the page can control whether layout changes or not.

07:16  Rossen_: The new page will be a new layout anyway, this should be a base case to be successful

07:16  khush: Going from one layout to another is the base thing we're trying to transition to

07:16  khush: Issue is that you figure out what your animation will be based on the final layout. If the user then changes things while the transition is going, what do you do?

07:17  flackr: Treating as a transition, you could retarget what the transition is going to if things shift

07:17  khush: That's actually what the current impl does, to try to make things happen smoothly

07:17  khush: If something shifts quite a lot right near the end, it'll look abrupt, but it'll look abrupt no matter what

07:18  JakeA: Related open question - to what degree do we freeze the incoming page during the transition? If we do, this problem goes away.

07:18  JakeA: Another benefit is that during a page load things shift around, it tends to cause jank

07:18  JakeA: Downside is that you might get a big shift at the end of the transition when everything moves to its final state

07:18  JakeA: And a jump for animations or gifs

07:19  Rossen_: Want to make sure we stay on the first topic about pixel snapshots

07:19  Rossen_: my understandign now is that you ahve the render list, post-layout construct, from the previous doc

07:19  Rossen_: i'm assuming this is pre-blending/etc, because you don't have the other context

07:19  Rossen_: So you're prone to "popping" in terms of color, etc

07:20  Rossen_: What's the handling there? Easing, don't worry about it, leave it popping by default, etc?

07:20  khush: Let me rephrase to understand

07:20  khush: You have a dom element being blended into its background. when the transition starts it'll blend into a different background. how do we make sure it's not distracting?

07:21  Rossen_: yes. I also think it should be a base req that you're not bleeding pixels from unrealted elements

07:21  q+

07:21 — Zakim sees chrishtr on the speaker queue

07:21  khush: You're right that when we capture, it's just the content of the subtree, before it's blended

07:22  khush: And for security reasons, you can't access any of the captured pixels

07:22  emilio: I assume the trnasition happens in the compositor - the pixels shouldn't end up in the content process at all

07:22  Rossen_: Unless the element lands in a canvas context somehow

07:23  emilio: How would that happen?

07:23 <Rossen_> q?

07:23 — Zakim sees chrishtr on the speaker queue

07:23  khush: from an impl perspective, we're treating these with the same security persepctive as we do with iframes

07:23  emilio: with Firefox that happens in the GPU process or the parent process

07:23  q+

07:23 — Zakim sees chrishtr, emilio on the speaker queue

07:24  Rossen_: So the intended behavior is to have "color popping"?

07:24  khush: what do you mean?

07:24  flackr: If you have opacity on a parent you'll see stuff behind it, but as soon as the transition starts you'll lose that blended background

07:24  khush: Isn't that what you'd always get?

07:25  flackr: Imagine you go from black background to white, and your element is gray and partially transparent

07:25  flackr: It'll look like it immediately switches

07:25  q?

07:25 — Zakim sees chrishtr, emilio on the speaker queue

07:25  q+

07:25 — Zakim sees chrishtr, emilio, vollick on the speaker queue

07:25  JakeA: There will indeed be some "popping", like if an element is partially clipped by a parent - it'll become unclipped because its parent no longer exists

07:26  Rossen_: Question isn't just with the background, but with things on top too, like if you have a screening element

07:26  q+

07:26 — Zakim sees chrishtr, emilio, vollick, khush on the speaker queue

07:26  Rossen_: In the transition it'll pop because that screener isn't there anymore

07:26  flackr: Yes, that's intentional

07:26  Rossen_: So that's popping by design?

07:26  [nods]

07:26 <Rossen_> q?

07:26 — Zakim sees chrishtr, emilio, vollick, khush on the speaker queue

07:26  Rossen_: Okay as long as that's explicit

07:26 <Rossen_> ack chrishtr

07:26 — Zakim sees emilio, vollick, khush on the speaker queue

07:27 — TabAtkins you can qq+ to jump yourself to the front of the queue

07:27  chrishtr: Also clips of ancestors don't apply for the same reasons

07:27  present+

07:27  chrishtr: It seems that transforms do need to apply

07:27  chrishtr: To keep the element in the right position

07:27  chrishtr: So you dont' want to apply some visual changes but not others

07:27  chrishtr: So this does have some wrinkles with other features

07:27 <Rossen_> q+

07:27 — Zakim sees emilio, vollick, khush, Rossen_ on the speaker queue

07:28  emilio: I was gonna ask about effects on parents and how they're handled, like clips

07:28 <Rossen_> ack emilio

07:28 — Zakim sees vollick, khush, Rossen_ on the speaker queue

07:28  emilio: You mentioend stacking contexts - is that sufficient to say "here's this element as a texture"?

07:28  emilio: Stuff can skip stackign contexts, like positioned children

07:28  chrishtr: The element will require something that contains its children. Right now we use contain:paint as the req

07:28  emilio: that's good

07:29  'sharing the element' is also a compositing trigger for us

07:29  emilio: It's not just contain:paint, you need info in the compositor - do you forcefully layerize contain:pain elements?

07:29  chrishtr: Not generally, but when you signal you want to transition an element, it signals the compositor to layerize and save off the texture.

07:29  emilio: So you need an API call on the page you leave as well as the page you go to

07:29  chrishtr: yes

07:30  vollick: Follow-on to Rossen's popping question

07:30  vollick: If I understand, those things that aren't included in the capture that would change, in a traditional case we coudl smoothly transition those

07:30  vollick: Wouldn't it be possible to have a smooth transition in this API as well if we capture that data?

07:30  vollick: Is this impossible?

07:31  khush: That's what was going thru my mind - I assumed you could set up the background so that you'll have a smooth transition

07:31  flackr: It's not just background - it's everything behind and in front of the element

07:31  q+

07:31 — Zakim sees vollick, khush, Rossen_, chrishtr on the speaker queue

07:31 <Rossen_> ack vollick

07:31 — Zakim sees khush, Rossen_, chrishtr on the speaker queue

07:31  q-

07:31 — Zakim sees khush, Rossen_, chrishtr on the speaker queue

07:32  khush: Occlusion is important, es. Keeping paint order of something on top is hard. Hoping that these are edge cases devs wont' run into often, so we can just do the simple thing.

07:32  ack khush

07:32 — Zakim sees Rossen_, chrishtr on the speaker queue

07:33  Rossen_: Discussion so far was about one element being transitioned. When you have a collection beign transitioned, what's the thinking there

07:33  Rossen_: Same limitations to all individually?

07:33  Rossen_: Blend and clip between them?

07:33  Rossen_: Say I've got three elements stacked on each other, not ancestors, that blend into each other's pixels, and I transition all of them

07:34 <Rossen_> ack Rossen

07:34 — Zakim sees chrishtr on the speaker queue

07:34  khush: So we capture independent snapshots of them

07:34  khush: The initial scene blends as you expect

07:34  khush: We ahve a "paired transition" concept

07:34  khush: Where you're going from A on the old to B on the new

07:34  khush: But in the new page the endpoints might be stacked differently

07:35  khush: It's not clear to me how these things should transition

07:35  khush: I was hoping for these questions to lean on the expertise of those here, I'm not sure

07:35  Rossen_: Okay, let's move on for now if we don't have ideas set yet

07:35  chrishtr: To sizing, if a resize occurs, this might hcange the size and position of the endpoint element

07:36  chrishtr: I think we should just adjust the curve the same way we do with CSS animations today

07:36  chrishtr: In addition, there's a global page transition that can occur as well, like a crossfade

07:36 <Rossen_> q?

07:36 — Zakim sees chrishtr on the speaker queue

07:36 <Rossen_> ack chrishtr

07:36 — Zakim sees no one on the speaker queue

07:36  chrishtr: That doesn't depend on layout, so even if the SET adjusts or aborts, the other transition still runs

07:38  khush: One takeaway question - is using snapshots of elements the right primitive to build on?

07:39  Rossen_: A followup for this case - in a resize transition, do you just rasterize that texture and then scale to the target size?

07:40  chrishtr: Yes, but similar to transform animation that scales - we don't specify precisely what's up with the pixels

07:40  chrishtr: We won't rerender text tho, just do some scaling on the gpu

07:40  khush: What you mentioned might be good to bring up now

07:40  khush: Seen some cases where you transition between rounded corners

07:41  khush: Weren't sure if we should rasterize those corners into the texture

07:41  q?

07:41 — Zakim sees no one on the speaker queue

07:41  TabAtkins: Like if it has 5px rounded corner, but end-point is twice as wide?

07:41  q+

07:41 — Zakim sees JakeA on the speaker queue

07:41  q+

07:41 — Zakim sees JakeA, vmpstr on the speaker queue

07:41  flackr: I think it would be nice to rasterize without the border clip and apply that post, like we would with filters

07:42  JakeA: I think that would be hard with rounded corners, those have a compound effect on borders and shadows

07:42  JakeA: Model I've been coming to is when we write to a texture, the dev can opt into properties that are excluded from the flattening, and become properties that can be animated in a CSS way

07:42 <Rossen_> ack JakeA

07:42 — Zakim sees vmpstr on the speaker queue

07:42  JakeA: We'd limit these to ones we agree can be done on a texture, like transform, opacity, filter

07:43  JakeA: If devs want to animate border-radius so they work at differetn aspect ratios, we do have clip-path; not the same, but can function similarly sometimes

07:43  JakeA: So question is if that's enough

07:43  flackr: Border and border-radius are also things you can apply on top of image-like content, right?

07:43  JakeA: It's also a layout, since border size changes content size

07:43  chrishtr: I think all the props that apply to self should still apply

07:44  chrishtr: Like an opacity on the element itself should apply

07:44  chrishtr: So if the shared element had "opacity:.5", the texture shoudl be partially transparent

07:44  Rossen_: My understanding, yes. It'll just blend against something different

07:45  chrishtr: Right, blend mode or backgrounf-filter implicitly take the background as input - they just don't work in a SET

07:45  JakeA: My issue is that right now no browser I know of can animate clip-path on teh compositor

07:45  JakeA: So we either make a set list and freeze it, or we make it opt-in and potentiallye xtensible

07:46 <Rossen_> q?

07:46 — Zakim sees vmpstr on the speaker queue

07:46  JakeA: [example of starting element using opacity, end elemetn using transparent color, and wanting these to act identically]

07:46 <Rossen_> ack vmpstr

07:46 — Zakim sees no one on the speaker queue

07:46  vmpstr: For the contents of the element we do want to cross-fade

07:46  vmpstr: Note this'll be a fairly quick transition, cross-fade looks nice

07:46  q+

07:46 — Zakim sees khush on the speaker queue

07:47  vmpstr: Thinking about border-radius and other content clips, to me woudl be weird to have clip path that animates to another while the contents cross-fade in the middle

07:47  vmpstr: I'd rather see the shape of the element be the contents of th eelement, and that crossfades

07:47  vmpstr: So that does mean that border-radiuses/etc stretch if the destination is significantly different

07:47  TabAtkins: Have seen exact effect, of border-radius stretching, in video games. Looks reasonable.

07:48  TabAtkins: if slow, weird, but if fast not a problem

07:48 <Rossen_> q?

07:48 — Zakim sees khush on the speaker queue

07:48  khush: We've had partners trying feature so far, and we're doing this exact thing (border radius baked into the texture) and this isn't a complaint

07:48 <Rossen_> ack khush

07:48 — Zakim sees no one on the speaker queue

07:48  khush: So next question is about allowing existing CSS animations to work in sync

07:48  khush: So here you declartively create animations

07:49  khush: People have tried to do CSS animations on the new dom and they want it to be in sync with this feature

07:49  TabAtkins: We have that timeline concept, right?

07:49  Rossen_: Which timeline?

07:49  flackr: The animation runs on the new document timeline

07:50  emilio: Seems problematic if the new page can be affected by 3rd party content

07:50  flackr: Yeah, if there's animations on the old content, it runs on the old timeline, but the SET runs on the new document timeline

07:50  chrishtr: I think the old-document animations just have to stop

07:51  chrishtr: And the transition just happens on the new timeline as if it's an element inserted

07:51  flackr: We could allow the old page to define a transition that happens during this SET, and that would run on the new timeline. Properties that are animatable would be very limited

07:51 <Rossen_> q?

07:51 — Zakim sees no one on the speaker queue

07:51  flackr: A little worried about splitting control between two pages

07:52  s/flackr/JakeA/

07:52  JakeA: LIke if you click an link and old page was v10, new page is v11

07:52  q+

07:52 — Zakim sees khush on the speaker queue

07:52  fantasai: I don't think we shoudl constrain what's possible bc we're concerned about deploying a new page in the middle of a transition

07:53  JakeA: Not necessarily during the trans, if it's deployed anytime after the old page loads

07:53  fantasai: Sure, but that's still a rare case, and it won't break the transition just maybe look weird. If that's what limits our API tho, that's a rpoblem

07:53  khush: Assuming the old animations are stopped and new content is on the new-doc timeline...

07:53  s/the transition/the page/

07:53  s/weird/weird during the transition/

07:53  khush: If you have a SET, and you do an animation that changes the new element's layout

07:54  khush: We're assumign some thing that stay the same for the target

07:54  khush: If you ahve a gif, we assume we can use the new gif frames as it's moving

07:54  q+

07:54 — Zakim sees khush, chrishtr on the speaker queue

07:54  khush: But if it changes its position, those become difficult to reason about

07:54 <Rossen_> ack khush

07:54 — Zakim sees chrishtr on the speaker queue

07:54  chrishtr: You're talkinga bout the old element changing?

07:54  khush: New element also

07:54 <Rossen_> q+

07:54 — Zakim sees chrishtr, Rossen_ on the speaker queue

07:55 <Rossen_> pack chrishtr

07:55  khush: So if you're doing CSS animations on the new page, which animations would run OK is what we need to define

07:55  chrishtr: I think it would work the same as if you simulated the same thing with CSS animations

07:56  Rossen_: Related: if your starting element is a 2x2 grid, your ending element is a 3x3 grid, this visual change is...?

07:56  TabAtkins: It's a crossfade, just pixels changing

07:57  JakeA: You could also transition the individual grid items if you wanted, then it can get more complex

07:57  Rossen_: Good point, this scenario has been requested; if this feature helps with these kinds of layout changes, it would be powerful

07:57 — fantasai q+ to ask about SPA transitions where the author wants the elements to be live

07:57 — Zakim sees chrishtr, Rossen_, fantasai on the speaker queue

07:58  khush: In such a scenario we do a scale and crossfade, but there are patterns where people want to do a clip-reveal; we hope this can be made customizable

07:58  khush: so stuff like that, we want to start with crossfade default but make it customizable

07:59 <Rossen_> q?

07:59 — Zakim sees chrishtr, Rossen_, fantasai on the speaker queue

07:59 <Rossen_> ack chrishtr

07:59 — Zakim sees Rossen_, fantasai on the speaker queue

07:59 <Rossen_> ack RRSAgent

07:59 — Zakim sees Rossen_, fantasai on the speaker queue

07:59 <Rossen_> ack Rossen

07:59 — Zakim sees fantasai on the speaker queue

07:59  TabAtkins: If you want to do where it reorganizes, you do shared element transition on the grid items individually, not just the grid container as a whole

07:59 <Rossen_> ack fantasai

07:59  fantasai, you wanted to ask about SPA transitions where the author wants the elements to be live

07:59 — Zakim sees no one on the speaker queue

07:59  chrishtr: I think Rossen wants the ability to make this done easily

07:59  fantasai: I think authors doing SPA want to do live element transitions, like when a video is playing

08:00  fantasai: and also to have more control over what exactly gets animated

08:00  fantasai: Is that something we want to consider allowing?

08:00  fantasai: If so, do we want to design the API to accommodate?

08:00  fantasai: And if so, do we want to leave open the possibility to do MPA transitions live, if perf isn't a concern?

08:00  q+

08:00 — Zakim sees vollick on the speaker queue

08:01  JakeA: I think that might be one of the things we're giving up to actuall deliver something

08:01  JakeA: Having both DOMs alive changes things pretty fundamentally

08:01  s/concern/concern in the future/

08:01  JakeA: We've got things like prerender where both doms are alive at the same time

08:01  JakeA: But if both pages are live with JS, say, that's complicated

08:01  JakeA: Also creates signif memory pressure

08:01  fantasai: Right, not expecting this today, but in the future we might not have the same constraints

08:02  fantasai: So animating props that are not on the set list might be possible in the future

08:02  JakeA: Right, I mentioned an opt-in for props animated in the texture vs outside

08:02 — Rossen_ I'm not seeing this explicitly stated but my hope is that this feature will allow a strict subset of transition/anim capabilities compared to in-page... This is important so we don't induce weird dev patterns where page transitions are used to achieve an effect

08:02  JakeA: And theoretically we could scale that up to "everything please"

08:03  khush: We've thought about how if you deal with this, how drastically it changes the feature

08:03  khush: And in the cross-origin scenario, the security gets so complex

08:03  q-

08:03 — Zakim sees no one on the speaker queue

08:03  fantasai: I think freezing script on the old doc could be quite reasonable

08:03  fantasai: But just animating CSS properties in a lot of ways might be something people might want, so leaving that open for the future

08:04  emilio: A lot of interactions with sessions history/bfcache - if you do something remotely observable, that's sketchy

08:04  s/the security gets/running JS on the old page and the security/

[chrishtr]

A new explainer has been published with an updated proposal for how this feature works, and in particular how it connects to existing CSS concepts. It proposes:

• re-using the top layer
• extensions to the element() function for live and cached element image references
• new pseudo-elements

We think that this approach layers well on top of existing CSS concepts with only small additions, particularly for caching the painted content generated using element() from the prior document. The feature has also been scoped to add new capabilities which incrementally build on these concepts.

We’d appreciate a CSSWG review of the CSS architecture of the proposal, to ensure that part is sound. With that in place, we can continue exploring the shape of the API that triggers these CSS behaviors, knowing we have a good basis.

[khushalsagar]

A slide deck explaining the feature design with an example and outlining the associated spec changes is here.

The main change since the previous update is introducing a new stacking context to paint the new pseudo-elements instead of the top-layer.

[astearns]

@khushalsagar for archival purposes, please export the slide deck to some format that you can attach in an email to www-archive@w3.org, then post the link you get from https://lists.w3.org/Archives/Public/www-archive/ here.

[khushalsagar]

Sure. I sent the email. Waiting for it show up in the archive and I'll post the link here.

[css-meeting-bot]

The CSS Working Group just discussed Shared Element Transitions.

The full IRC log of that discussion

<fantasai> Topic: Shared Element Transitions
<khush> For the upcoming press.
<chris> https://docs.google.com/presentation/d/15y60zFddT859VHKNeH6bjJyrZ1wIr8W7VUfRfr-icIk/edit#slide=id.p
<fantasai> khush: Going to use a very simple example
<dbaron> (khush explained that he sent it to www-archive but it's waiting for approval)
<fantasai> [slide 2]
<fantasai> khush: ...
<fantasai> khush: Core design in both states
<fantasai> khush: what to highlight new CSS attribute callled page transitions tag
<fantasai> khush: During transition we create alternate representation of DOM after snapshotting
<fantasai> khush: Page tells us which parts to shapshot as independent pieces
<fantasai> khush: This is saying root element should also be captured
<fantasai> khush: Other apect is properties that are changing
<fantasai> [slide 3]
<fantasai> khush: This slide shows box tree during transition
<fantasai> khush: have root stacking context, author dom underneath
<fantasai> khush: during transition we create tree of pseudo-elements that is sibling of root stacking context
<dbaron> github: https://github.com//issues/6464
<fantasai> khush: highlight fact that this transition stacking context, it paints as a sibling of the root context
<fantasai> khush: reason is, these content elements are displaying images from author dom
<fantasai> khush: it's displaying root stacking context
<fantasai> khush: inintially tried to place n top layer, but ran into circular dependencies
<fantasai> khush: wanted to capture other elements in top layer
<fantasai> khush: so put it in an independent stacking context as sibling of root
<fantasai> [slide 4]
<fantasai> khush: on the left dom structure, on the right stylesheet from UA
<fantasai> khush: focus on container element
<fantasai> khush: we have layout computed properties for each element with a page-transition tag
<fantasai> khush: and we have transform that maps into ?? space
<fantasai> khush: UA that generates, box renders at same spot that renders in author DOM
<fantasai> khush: Last is z-index for paint ordering
<fantasai> khush: we compute that anduse z-index to paint in same order in peudo tree
<fantasai> khush: container get us box that maps to actual element's box
<fantasai> khush: content fo element comes from ??? proeprties
<fantasai> khush: Using element in CSS to get a painted representation of the DOM element's contents
<vmpstr> s/???/old-content and new-content/
<fantasai> khush: this is a snapshot of element in the new dom
<fantasai> khush: the old one is snapshot of old content with cacehed element
<fantasai> khush: we cache a static paint to retain the content of the old dom
<fantasai> khush: then DOM changed to new state
<fantasai> [slide 5]
<fantasai> khush: Previous slide showed transition pseudo element tree and how to make it look like author dom
<fantasai> khush: this shows the animations shoing change from old to new state
<fantasai> khush: first animates box from old size andposition to new size and position
<fantasai> khush: for the content just do a swap, old content fadesin / new content fades out
<fantasai> khush: because of all the pseudo elements exposed to developer, can customize any way they want
<vmpstr> [slide 6]
<fantasai> khush: this slide meant to highlight the ...
<fantasai> khush: want to approximate the rendering as much as possible
<fantasai> khush: issue with inherited properties
<fantasai> khush: won't retain inherited from ancestors, but will ...
<fantasai> khush: When generating snapshot, doesn't include any effects from ancestors
<fantasai> khush: Everything with a page-transition tag paitns in ame orderin pseudo-element treee
<fantasai> khush: but if element ?? wasn't tagged, then its content is in the root element image
<astearns> s/.../retain positioning and screen space transforms/
<fantasai> khush: and this will cause a paint order change
<fantasai> khush: Last is the liveness of DOM, old DOM is static, but new dom is live-updated
<fantasai> khush: By design; that's how element() function works today
<smfr> next silde
<fantasai> [slide 7]
<fantasai> khush: list of spec changes
<fantasai> khush: First is to update the element() spec
<fantasai> khush: right now element() generates an element that is size of element's bounding box
<fantasai> khush: ink overflow is getting lcipped
<fantasai> fantasai: don't think you can include the ink overflow
<fantasai> fantasai: because then size of image is unpredictable
<fantasai> fantasai: and ink overflow is potentially infinite, and where it gets clipped will vary by implementation
<TabAtkins> scribe+ TabAtkins
<fantasai> s/unpredictable/unpredictable, and can't be accurately positioned by the author/
<fantasai> khush: Next is stnadardizing the pseudo-element tree
<fantasai> khush: so need to spec that
<fantasai> khush: then need to define new stacking context for transitions
<fantasai> khush: and because of ink overflow, need to define that replaced element can overflow its box
<fantasai> khush: blending pixels, have a proposal to allow that
<fantasai> khush: Right now actively implementing this
<fantasai> khush: want to get feedback in WICG on issues like fantasai raised
<fantasai> khush: as implementation matures will discuss issues
<fantasai> astearns: Suggest participating in repo, would like to get this feature right
<fantasai> astearns: On the call want to discuss if any serious concerns with the direction being proposed
<fantasai> smfr: Various limitations in escaping ancestor effects like opacity and filters
<fantasai> smfr: makes me think people will write pages ...
<fantasai> smfr: pop out of ancestor opacity and then nmove
<fantasai> smfr: seems limitation of implementation, only snapshotting things and not the whole tree?
<fantasai> khush: 2 additions
<fantasai> khush: right now snapshotting the whole element
<fantasai> khush: but added a mode where only snapshottong ?? and keep decorations and other things
<fantasai> khush: the other mode also snapshots highlighting etc. (????)
<fantasai> khush: Want to get there, but incrementally
<fantasai> khush: can point to explainer
<fantasai> khush: don't have issue of ancestor effects not being preserved
<fantasai> smfr: Showed pseudo-element hierarchy
<fantasai> smfr: you're snapshotting old content
<fantasai> smfr: using speudo-elements to define animations
<fantasai> smfr: but no DOM node behind that
<fantasai> khush: Once cached the state, need to be able to represent
<fantasai> khush: to get the rendering to look like author DOM, we made a tree of pseudo-elements
<fantasai> smfr: There are some similarities with things like animation-worklet
<fantasai> smfr: where you have a little JS world where you are limited in what you can do, but this is a little different
<fantasai> khush: Because pseudo-elements, limits in what you can do
<fantasai> khush: e.g. introducing own notes in tree or changing structure of tree
<fantasai> khush: getting to work with those requests is difficult
<fantasai> khush: limitations are defined here by what you can do with pseudo-elements
<fantasai> khush: so you can change their style, but not their structure
<fantasai> khush: can animate using CSS animations
<fantasai> smfr: can you apply arbitrary properties?
<fantasai> khush: yes
<fantasai> smfr: so you are running layout on the tree
<fantasai> khush: WE had cases where box aspect ratio was changing, wanted not to stretch but to clip, so set 'object-fit' and it just work
<fantasai> smfr: when p-e tree is showing, is it sitting on top and cans ee document underneath?
<fantasai> khush: in UA stylesheet we set 'visibility: hidden' on elements with page-transition tag
<fantasai> khush: don't actually show the page content, but still there
<fantasai> khush: if changing small part of page, don't put page-transition tag on the root
<fantasai> khush: so that keeps showing new DOM
<fantasai> khush: but see the transitions on top of it
<fantasai> smfr: ?????
<fantasai> khush: ....
<fantasai> khush: and then we save the hierarchy as well
<astearns> s/?????/is the old page content a snapshot?/
<astearns> s/..../yes/
<smfr> is the old page content a snapshot
<fantasai> smfr: so if page content has animation, that will freeze
<fantasai> khush: yes
<fantasai> khush: new DOM is live, but old DOM is frozen
<fantasai> astearns: Suggest putting links to the specific parts of explainer/issue that respond to the things discussed here
<fremy> just in general, I think this is a very interesting proposal
<fantasai> jensimmons: Also helpful to have resources to explain author experience
<fantasai> khush: The explainer takes an example of one page, and has the author CSS that you need to get the transition working. I'll link to that section also
<fantasai> astearns: Fine to put Agenda+ either on this meta-issue or adding a new issue, to discuss particular parts of this proposal
<fantasai> astearns: would rather do that than doing general discussion again
<fantasai> astearns: Thanks very much for presentation, very cool stuff.

[khushalsagar]

Adding link to questions raised during the presentation today :

• Concern about increasing image size to use ink overflow since it can be infinite. This was discussed in the issue here to describe how a snapshot should be clipped if the UA can't cache its entire content. Other than ink overflow, this is an issue in general because an element's bounding box (which element() currently sizes the image to) can be huge and the UA needs to clip it.

• Concern about ancestor effects getting clipped. We've proposed 2 modes which address this as incremental additions. First is caching an element's state as a snapshot of its descendents and its computed style and second is preserving the hierarchy of tagged elements in the pseudo tree representation. The motivation behind doing these as extensions was because there are use-cases where not preserving hierarchy is desirable and the base model addresses a lot of use-cases already.

• What happens to the author's DOM element when the transition pseudo tree is showing? We force visibility:hidden on the DOM element while it's being painted using the pseudo element. It's shown in the UA style sheet here. We need some syntax to target these elements in a UA sheet.

• How would authors would set up transitions using this : Example in the explainer shows how a transition can be set up by a developer using only CSS.

[khushalsagar]

And here's a link to the email which has a pdf of the slide deck referenced in the comments.

[fantasai]

Well the other bit you maybe missed is that if the result of element() is an image with an unpredictable bounding box, it's a problem. For example, if element() is used in 'background-position' or 'content'. The author is positioning the image themselves in these cases, and they can't know that the actual border box of the image is 17px into the image because the flourish on a cursive letter is leaking.

[khushalsagar]

For overflow, I was thinking about having an option to specify an explicit overflow that a developer could also use with element(). It would be similar to overflow-clip-margin, like element(id, {overflow: 5px}). And then the image is always expanded by this size and the actual border box is consistently at the exact offset. For this feature, this offset could be UA provided.

But there is another scenario where the size of images we're creating for transitions is different from element(), the clipping issue for massive elements I mentioned above. We're evaluating the ways in which the requirements on snapshots for this feature differ from element(). And it might be better to introduce a new function which is conceptually similar to element() but explains those differences better.

[vmpstr]

Spec draft for Shared Element Transitions: https://tabatkins.github.io/specs/css-shared-element-transitions/

[css-meeting-bot]

The CSS Working Group just discussed Shared Element Transitions, and agreed to the following:

• RESOLVED: Add Shared Element Transitions as ED, with JakeA, khush, and TabAtkins as editors

The full IRC log of that discussion

<fantasai> Topic: Shared Element Transitions
<fantasai> Rossen_: welcome to Day 2
<dbaron> github: https://github.com//issues/6464
<vmpstr> vmpstr
<fantasai> vmpstr: About Shared Element Transitions, a new set of APIs we're working on for animations and transitions between pages
<fantasai> vmpstr: single page and hopefully multipage as well
<fantasai> vmpstr: Was presented in breakout session
<fantasai> vmpstr: since then worked on spec text and prototype in Chromium as well
<vmpstr> https://tabatkins.github.io/specs/css-shared-element-transitions/
<fantasai> vmpstr: I sent this spec draft to the list awhile back
<fantasai> vmpstr: hoping that ppl interested would have read through the draft
<fantasai> vmpstr: ultimate goal for us is adopting this into the CSSWG
<fantasai> vmpstr: so we wanted to use this opportunity to surface issues ppl may have
<fantasai> vmpstr: and of course we're happy to answer any questions
<fantasai> khush: Other goal that I'm hoping is, there are a few open issues in the spec and things came up while prototyping
<fantasai> khush: and wanted to go over those as well
<fantasai> khush: hoping we can file issues within CSSWG and go from there
<fantasai> Rossen_: We've had the overview in the past, there's also an open aggregate for this feature, which we haven't gotten to
<fantasai> Rossen_: questions or comments or feedback to vlad and khushal?
<fantasai> Rossen_: what do they need to move forward and adopt this as part of the CSS charter?
<fantasai> Rossen_: do we need any additional overview, refresher of the APIs?
<fremy> q+
<fantasai> TabAtkins: Happy to discuss any concerns, but also if OK with making ED can discuss later as wel
<fremy> q-
<fantasai> fremy: I like the idea, just note that there is no images or diagram or anything in the draft
<fantasai> fremy: so maybe in a future version, have a diagram of the different pseudo elements
<Rossen_> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
<fantasai> fremy: and what order they're in the page
<fantasai> fremy: it's in Ch4, but a diagram would be nice
<fantasai> fremy: not a blocking thing
<fantasai> Rossen_: I posted also a link to the explainer, a bunch of really well-illustrated examples there
<JakeA> Updated developer-facing article https://developer.chrome.com/blog/shared-element-transitions-for-spas/
<fantasai> fremy: exactly what I was hoping for
<JakeA> q+
<fantasai> Rossen_: anything else, fremy ?
<fantasai> fremy: nope
<Rossen_> ack JakeA
<fantasai> JakeA: I posted a link to the developer-facing content for this, which includes a lot of videos and examples
<fantasai> JakeA: can put it in the spec if wanted
<fantasai> JakeA: I've never seen a video in a spec before!
<fantasai> TabAtkins: of all this specs, this is probably the one that would most benefit!
<fantasai> Rossen_: Any objections to adopting this work?
<fantasai> fantasai: Are we adopting an ED, or are we also publishing FPWD
<fantasai> TabAtkins: still have some tweaks to make, so happy to wait until we get those down and then doing FPWD
<fantasai> fantasai: If you have planned edits, let's do ED now and FPWD later then.
<fantasai> RESOLVED: Add Shared Element Transitions as ED, with JakeA, khush, and TabAtkins as editors
<fantasai> Rossen_: anything else on this topic?
<bramus> Nice!
<vmpstr> \o/

[khushalsagar]

I'm adding agenda+ to the issue to resolve on accepting the current spec as the First Public Working Draft. The core approach is outlined in the spec now and remaining issues are minor edge cases.

[jakearchibald]

Rossen_: Any objections to FPWD?
RESOLVED: FPWD Shared Element Transitions
ACTION: fantasai help publish

Resolved to move to FPWD at TPAC.

[fantasai]

Published so closing out