- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Jul 2024 16:47:46 +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: UA is allowed to capture old elements in low resolution if they are off-screen` <details><summary>The full IRC log of that discussion</summary> <fantasai> noamr: We were discussing optimization to render new live element in place of old element snapshot for when it's offscreen<br> <fantasai> noamr: but there were some concerns from WebKit wrt having two live images<br> <noamr> https://github.com/w3c/csswg-drafts/issues/8282#issuecomment-2245542731<br> <fantasai> noamr: Discussed using transparent image, but that would create a cross-fade that's not necessarily what's wanted<br> <fantasai> s/cross-fade/fade-in/<br> <fantasai> noamr: could make it implementation defined, but we lose compatibility here<br> <fantasai> noamr: another option is to figure out the implementation<br> <fantasai> noamr: Option I like the best is keep spec as-is, but say that if an element is off-screen, the UA can capture it at low resolution<br> <fantasai> noamr: so if you have elements cross-fading from far away, might appear blurry<br> <fantasai> noamr: also, using view-timeline, authors that want to override can do so<br> <fantasai> noamr: by giving a different view transition class and use a different animation<br> <fantasai> noamr: other option that was raised was to make one capture at the beginning of the new element, and use that as the old element<br> <khush> q+<br> <Rossen2> ack khush<br> <fantasai> khush: I like idea of having UA decide the rasterization range<br> <fantasai> khush: and browser can make trade-offs based on, is this a low-end device, etc.<br> <TabAtkins> fantasai: I think the idea of doing [missed] and a capture of the new state is interesting. not sure what makes the msot sense, tryign to get Tim to sign on<br> <fantasai> s/[missed]/low-res captures<br> <fantasai> noamr: Concern with using new image as old image is the semantic difference<br> <fantasai> noamr: Want to also not create junk<br> <flackr> s/junk/jank<br> <fantasai> fantasai: You mentioned could capture low-res or not at all<br> <TabAtkins> fantasai: If you have something that isnt' captyured; you're saying an opt is a low-res or not capturing at all, if you realize partway thru that you need the old image and didn't capture it, what do you do<br> <vmpstr> q+<br> <noamr> you'd see whatever it is you've captured<br> <fantasai> flackr: you'd either capture or not up front, and then have transparency if didn't capture<br> <Rossen2> ack vmpstr<br> <fantasai> vmpstr: Another option is we don't capture anything in the old, but we also don't do the cross-fade by default<br> <fantasai> vmpstr: only display the new pseudo-element<br> <noamr> (rejoining call)<br> <Rossen2> ack fantasai<br> <TabAtkins> fantasai: for "only dispaly the new element", I think in that case you'd need to somehow allow the author to select those cases<br> <TabAtkins> fantasai: so if *they're* doing a cross-fade they'll realize they can't do it<br> <khush> q+<br> <TabAtkins> fantasai: if their animation depends on the old image existing, so they can adapt to it<br> <TabAtkins> fantasai: So on the "this is an optimization" perspective, doing a low-res capture makes more sense to me<br> <TabAtkins> fantasai: In cases where the UA didn't capture the old el and realized they need it, I think transparent might be problematic<br> <TabAtkins> fantasai: So instead in that case, if you optimzie too hard, just take a cpature of the new dom and use that instead<br> <fantasai> vmpstr: Low-res capture cross-fading to that might have artifacts that are unappealing<br> <TabAtkins> fantasai: to be clear, not saying... you'd only use the new dom in place of the old if you'd *failed* to catpure anything at all. if you have a lowres capture you shoudl use that<br> <fantasai> khush: On aspect of authors should be able to detect this"<br> <fantasai> khush: for not capturing the old<br> <fantasai> khush: would it be enough to give the author a pseudo-class?<br> <fantasai> khush: UA would not do a cross-fade, and the author can then do a customization<br> <vmpstr> +1<br> <Rossen2> ack khush<br> <fantasai> khush: [something] is not trivial to do<br> <fantasai> khush: implementation concerns were raised on WK side<br> <noamr> q+<br> <fantasai> noamr: aside from being detectable, also want good default<br> <fantasai> noamr: I like the idea of having one capture of new element in the rare case where we didn't capture anything<br> <Rossen2> ack noamr<br> <fantasai> ntim: I would prefer low-res capture of the old state<br> <fantasai> ntim: I think that's the easiest thing to implement<br> <noamr> q+<br> <fantasai> ntim: for authors [garbled]<br> <fantasai> ntim: show nothing solution is more disruptive to the user<br> <fantasai> noamr: I would suggest something<br> <Rossen2> ack noamr<br> <fantasai> noamr: we say that you can display low-resolution image of the element<br> <fantasai> noamr: that way we discourage showing totally transparent images<br> <fantasai> noamr: we don't have to resolve on what happens when we didn't capture anything right now<br> <fantasai> noamr: we can capture a low-res image, and we discourage capturing fully transparent<br> <fantasai> noamr: if there's an issue, we can resolve on it then; might not be necessary<br> <khush> q+<br> <fantasai> ntim: low-res of old capture seems reasonable to me<br> <Rossen2> ack khush<br> <fantasai> khush: do we want authors to be able to detect this?<br> <fantasai> khush: low-res cross-fade could be looking bad<br> <fantasai> vmpstr: use case would be e.g. grid-reorder where image is coming in from far off the screen<br> <fantasai> khush: right now you see the same content, but now you'd see cross-fade between low-res and high-res<br> <fantasai> vmpstr: can detect if something came from offscreen using view-timeline<br> <fantasai> vmpstr: e.g. in grid-reordering case<br> <fantasai> vmpstr: maybe we can resolve on the degradation in a different resolution<br> <khush> i'm ok with that<br> <vmpstr> yep., that's fine<br> <fantasai> ntim: agree with noamr, detecting degradation should be a separate issue so we can get the syntax right<br> <fantasai> ntim: but right now you can detect animations from off-screen<br> <fantasai> s/vmpstr/noamr/<br> <fantasai> s/vmpstr/noamr/<br> <fantasai> s/vmpstr/noamr/<br> <flackr> q+<br> <fantasai> noamr: proposed resolution, if old element is off-screen, UA can capture in low resolutoin<br> <fantasai> flackr: should we change the UA animation at least to use the new image, since we know that's better?<br> <fantasai> noamr: That defeats the purpose<br> <fantasai> flackr: developer animation would still work using old image<br> <fantasai> flackr: but the UA animation would not need cross-fade..<br> <Rossen2> ack flackr<br> <fantasai> flackr: so this doesn't fix not needing to capture issue?<br> <fantasai> noamr: it fixes a perf issue, a lot less memory etc.<br> <fantasai> RESOLVED: UA is allowed to capture old elements in low resolution if they are off-screen<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-2248477031 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 July 2024 16:47:47 UTC