-
Notifications
You must be signed in to change notification settings - Fork 659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: shared element transitions #6464
Comments
The CSS Working Group just discussed 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 |
Recording of presentation: https://www.youtube.com/watch?v=UIWZFXwAPxE |
Minutes of 2021-09-02 discussion
|
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:
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. |
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. |
@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. |
Sure. I sent the email. Waiting for it show up in the archive and I'll post the link here. |
The CSS Working Group just discussed 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. |
Adding link to questions raised during the presentation today :
|
And here's a link to the email which has a pdf of the slide deck referenced in the comments. |
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. |
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. |
Spec draft for Shared Element Transitions: https://tabatkins.github.io/specs/css-shared-element-transitions/ |
The CSS Working Group just discussed
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/ |
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. |
Resolved to move to FPWD at TPAC. |
Published so closing out |
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
The text was updated successfully, but these errors were encountered: