Re: [csswg-drafts] [css-view-transitions-2] Ignore offscreen elements from participating in transitions (#8282)

> Feels more like something to put as a descriptor in the @view-transition at-rule, as this applies to the VT as a whole instead of individual elements.

Wouldn't authors have cases where this is different for different elements?

> It would break all "slide in/out from the top/side/bottom" transitions.

Just to be clear, it won't break a slide in from out-of-viewport type entry (name only in new DOM) animation. If the element in the new DOM is onscreen, it'll get captured and you can make its pseudo slide in from out of viewport to its final state. Same thing for exit (name only in old DOM) animations.

But yea, the list example you gave where you swap the first and last entry, and the last entry is offscreen, would break.

> I guess advice to developers would be: Browsers are about to break your transitions. Add * { view-transition-inclusion-area: everywhere } to prevent this 😄

Ha, well if authors end up using that CSS then changing the current behaviour is moot. I feel like you're convinced that authors will know to not put a `view-transition-name` unless that element needs to be animated, i.e., it will come onscreen during the transition. And changing the default here will just get in their way.

I'm worried that won't be the case, especially as we make it easier to declaratively add names with features like https://github.com/w3c/csswg-drafts/issues/8320. But I also don't have any other idea for avoiding this perf footgun...

So let's keep the current behaviour. Also easier from an implementor standpoint, no compat risk to deal with. :)

-- 
GitHub Notification of comment by khushalsagar
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8282#issuecomment-2049390619 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 11 April 2024 10:29:12 UTC