- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jun 2024 14:28:33 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Ignore offscreen elements from participating in transitions`, and agreed to the following: * `RESOLVED: We will design an optimization for VT of "offscreen" elements wherein we don't capture the bitmap for their offscreen state. Details TBD.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> khush: two problems<br> <TabAtkins> khush: one on my mind intiially, one brought by authors later. i'll talk about author problem first<br> <TabAtkins> khush: the way we decide aniamtions during an aimtion is the classic FLIP - start state, end state, set up an animation using it<br> <TabAtkins> khush: ways to have header/foother on the page that can be scrolled away<br> <TabAtkins> khush: might be super far away after scrolling<br> <TabAtkins> khush: simple FLIP animation gives a 1000px translation happening in 250ms which is mostly offscreen, which is effectively no animation - only on screen in last frame<br> <TabAtkins> khush: can work around it with intersectionobserver and conditionally put a name on it<br> <TabAtkins> khush: not great, needs JS<br> <TabAtkins> khush: so want a declarative way - rather than have a morph animation, make it entry/exit if the start/end state is offscreen<br> <TabAtkins> khush: my issue was - if you put a name on something, no matter how offscreen it is (content-visibility aside) then the browser will render it<br> <TabAtkins> khush: worse than style and layout, have to actually paint, and keep those pixels in memory<br> <TabAtkins> khush: costs a lot to do offscreen rednering<br> <TabAtkins> khush: and in the common case, offscreen things stay offscreen. then spending those resources for nothing.<br> <TabAtkins> khush: was hoping this could be used to let authors optimize this case for thsemelves. maybe even change the default behavior.<br> <TabAtkins> khush: three qs<br> <TabAtkins> khush: first, how to define offscreen<br> <TabAtkins> khush: related to the reference rect discussion, we want ink overflow, and i think that's sufficinetly specced now<br> <TabAtkins> khush: consistent with anchor pos too<br> <TabAtkins> khush: second, syntax<br> <TabAtkins> khush: lot of options on this issue<br> <TabAtkins> khush: proposing view-transition-visibility: visible | clip<br> <TabAtkins> khush: in the issue was suggested to match position-visibility value space, always | not-clipped<br> <vmpstr> q?<br> <bramus> q-<br> <vmpstr> q+<br> <TabAtkins> khush: we can bikeshed thenames<br> <TabAtkins> khush: 3, should we make clipping the default behavior?<br> <ydaniv> q+<br> <TabAtkins> khush: so easy to have offscreen content animating without realizing<br> <TabAtkins> khush: some author pushback, because this isn't just perf, it changes the animation<br> <TabAtkins> khush: like if you have a list, you delete an item, the next item is just offscreen, it just fades in rather than morphing<br> <TabAtkins> q+<br> <astearns> ack vmpstr<br> <TabAtkins> vmpstr: to add to pushback cases, i think the default is web-breaking, to be clear<br> <TabAtkins> changing the default, that is<br> <TabAtkins> vmpstr: some pushback on using viewport + ink-overflow<br> <TabAtkins> vmpstr: it's a very binary behavior, no smooth in-between<br> <TabAtkins> vmpstr: may be awkward to have such a different experience based on 1px scroll difference<br> <astearns> ack ydaniv<br> <TabAtkins> ydaniv: regarding name, my proposal is overflow, becuase visibility of VT sounds like your'e changing the visibility of the transition itself<br> <TabAtkins> ydaniv: overflow, sound slike you're talking about what you're clipping, or about elements that overflow the viewport<br> <TabAtkins> ydaniv: so view-transition-overflow: clip | visible<br> <TabAtkins> ydaniv: I think the use-cases are really common tho, think we should take care of it<br> <TabAtkins> ydaniv: need something to let it get clipped, don't blow up just because i have some things out of view<br> <TabAtkins> ydaniv: and if we add overflow-inset or margin, to increase level of tolerance<br> <astearns> ack TabAtkins<br> <astearns> q+<br> <fantasai> TabAtkins: I also have a minor objection to using the same definition as anchor-visibility does<br> <khush> q+<br> <fantasai> TabAtkins: I think it should be more like content-visibility where it's UA by default<br> <fantasai> TabAtkins: but also has a bit of margin of offscreen, so that you're ready<br> <fantasai> TabAtkins: it's not just offscreen, it's wayyy offscreen, so the animation is not visible at all<br> <fantasai> TabAtkins: So larger margin, smae concept as content-visibility<br> <fantasai> TabAtkins: don't think we need exact precision for it<br> <vmpstr> q+<br> <fantasai> TabAtkins: anchorpos needs it to be immediately as soon as it goes offscreen, because that's the use case<br> <TabAtkins> khush: i mentioned this exact thing on the issue, the dev response was with c-v the fact there's a ua-defined margin is there's a big perf thing, you don't see the difference based on the ua's choice<br> <vmpstr> q-<br> <vmpstr> +1<br> <TabAtkins> khush: if i'm debugging and see one behavior on chrome i won't chekc safari for a different behavior<br> <TabAtkins> khush: so point was to be explicit, since it changes the visual animation<br> <TabAtkins> khush: we can add a margin and let devs control<br> <fantasai> TabAtkins: viewport + margin is what I care about<br> <fantasai> TabAtkins: don't want super abrupt case<br> <fantasai> TabAtkins: We're either doing X or Y, it's abrupt<br> <ydaniv> q+<br> <astearns> ack astearns<br> <fantasai> TabAtkins: making it explicit and not paying cost for invisible frames just acknowledging the reality<br> <TabAtkins> astearns: i think an addition margin helps but doesn't entirely fix<br> <TabAtkins> astearns: i fyou have a list of cards, you're deleting some, and 3 or 4 move up into view - it's weird that some close to the view have a smooth transition while further ones are fading in<br> <TabAtkins> astearns: can do a larger margin, but still hit the case for things sufficiently far away<br> <astearns> ack khush<br> <TabAtkins> astearns: so i think i disagree we're fixing *only* the case where none of the naimation is being visible, it's also affecting where *less* of the animation is visible<br> <TabAtkins> (that's why we'd ahve something controllable, fwiw<br> <TabAtkins> )<br> <TabAtkins> khush: noam brought up a point - this feature is right now combining two aspects - whether the elemnt is offscreen or not, and what the browser shoudl do when it is offscreen<br> <TabAtkins> khush: noam's suggestion is to expose the state to the author. we dont' change wehther we capture or not, but let you know the elment was offscreen in one state (pseudo-class) so you can choose to react to that<br> <fantasai> TabAtkins: Doesn't solve perf problem though<br> <TabAtkins> khush: that's true, it's why i was pushing back<br> <TabAtkins> khush: i have another issue for the same perf problem<br> <TabAtkins> khush: like, if something is offscreen, we capture the box, just not its painted contents<br> <TabAtkins> khush: then we just don't cross fade, jsut use the new paint<br> <fantasai> TabAtkins: I quite like that<br> <fantasai> TabAtkins: fixes the case Alan spoke about<br> <fantasai> TabAtkins: and in general, seems like it's muuuch more likely to be compatible with existing content<br> <fantasai> TabAtkins: because geometry of animation is identical between now and new version<br> <fantasai> TabAtkins: only change is appearance in all but final frame, and only slightly<br> <fantasai> TabAtkins: so that sounds great<br> <TabAtkins> vmpstr: and if you're reordering lists and content isn't changing, you can just disable the crossfade and only show the new content, this solves that problem<br> <TabAtkins> khush: in most of these cases you really just want the transform, not the crossfade or size<br> <TabAtkins> khush: might want to think about size at all<br> <TabAtkins> khush: but if it's just moving, tkhis works perfectly well<br> <astearns> ack ydaniv<br> <TabAtkins> ydaniv: can you repeat the suggestion?<br> <TabAtkins> khush: [repeats it]<br> <TabAtkins> khush: and i think that's ok becuase you want to cross-fade when both old and new is visible to the user. if one state wasn't visible, no need to crossfade<br> <TabAtkins> ydaniv: yeah. and to alan's point, right now everything is captured, so you'll see all the cards.<br> <TabAtkins> ydaniv: I think the suggestion is that you'll clip.<br> <astearns> ack fantasai<br> <TabAtkins> [not 100% sure i captured ydaniv properly there]<br> <TabAtkins> fantasai: +1 to this idea too<br> <TabAtkins> fantasai: and for the pseudo-element indicating what's happening<br> <TabAtkins> fantasai: pseudo-class<br> <TabAtkins> fantasai: i think you need to expose all three cases - off-screen start, end, or both<br> <ydaniv> s/I think the suggestion is that you'll clip./the suggested property is an opt-in so you're asking to clip it for you when you want to optimize/<br> <TabAtkins> fantasai: maybe :offscreen and :offscreen(start | end | both)<br> <fantasai> s/start | end/new | old/<br> <TabAtkins> flackr: case to consider - new is above the screen, old is below the screen, so the animation passes *thru* the screen<br> <TabAtkins> fantasai: yes, interesting, should think about it<br> <TabAtkins> fantasai: might want to not transition at all<br> <TabAtkins> bramus: or might want to explicitly see that - if you're reordering a list and the part on screen stays still, want an indicator that the rest is flying around<br> <TabAtkins> fantasai: so want to consider the conditional styling there<br> <TabAtkins> khush: guess in that case you jsut want the current behavior<br> <TabAtkins> khush: whatever animation the browser sets up today<br> <TabAtkins> flackr: I think you'd be able to skip the capture, but still animate the new image<br> <fantasai> TabAtkins: Falls into same problem as you might see only 1 frame of the animation<br> <fantasai> TabAtkins: I think we can probably use the new state render for that and call it a day<br> <TabAtkins> astearns: so should we take all this discussion to the issue and synthesize a new proposal?<br> <TabAtkins> fantasai: seem to have agreement to pursue keeping the element, nto capturing the bitmap<br> <flackr> +1<br> <ydaniv> +1<br> <TabAtkins> fantasai: and maybe a pseudoclass for doing something special when something is offscreen<br> <fantasai> astearns: by how much offscreen?<br> <fantasai> TabAtkins: I think we can let the UA define<br> <fantasai> flackr: could be somewhat similar to content-visibility<br> <fantasai> vmpstr: new property or change behavior?<br> <fantasai> TabAtkins: I think you could just change the behavior.<br> <fantasai> astearns: How about we resolve that we want to add an optimization for offscreen and continue<br> <TabAtkins> astearns: let's jsut resolve that we want to add an optimization for VTs of offscreen elements. continue the discussion in the issue.<br> <TabAtkins> fantasai: I think we are specific about the bitmap dropping<br> <TabAtkins> astearns: proposed: we *will* add an optimization for offscreen things where we wont' retain the bitmap<br> <TabAtkins> RESOLVED: We will design an optimization for VT of "offscreen" elements wherein we don't capture the bitmap for their offscreen state. Details TBD.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8282#issuecomment-2165842379 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 June 2024 14:28:34 UTC