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