search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.35k stars 641 forks source link

[css-anchor-position-1] Dealing with accelerated CSS animations and containing block overflow #9351

Open vmpstr opened 9 months ago

vmpstr commented 9 months ago

The spec talks about dealing with scrolling. Since it can be done on a different thread and cause overflow, which results in layout inducing anchor() changes. It deals with it by doing snapshotting of scroll positions.

However, there are other accelerated effects, e.g. transform animations. These can also cause the positioned elements to overflow its containing block. Should we come up with a proposal on how to deal with these as well?

Also, not sure how scrolling behavior changes affect scroll timeline, since positioned element location is being determined as if everything is scrolled to the beginning. Does this mean the scroll timeline is also at the beginning and the scroll driven animations go to the start? Since the delta between scroll position and scroll driven animation element is not necessarily a translation

xiaochengh commented 9 months ago

I think we should split this into two issues:

  1. How anchor positioning and transforms should work with each other. Right now we simply make them ignore each other, because we don't have a good alternative idea
  2. How anchor positioning and scroll timeline should work with each other. This part is unspecified right now
vmpstr commented 9 months ago

I've pulled the scroll driven animation issue into https://github.com/w3c/csswg-drafts/issues/9379

vmpstr commented 9 months ago

One thing that I think makes dealing with transforms a lot easier is if having a transform establishes an achor-scope, much like it establishes a containing block for fixed position elements.

My understanding is that it would break cases like having a transform on a selectmenu, where the anchored element must be outside of the element. However, I think those cases are already broken under transforms.

xiaochengh commented 9 months ago

My understanding is that it would break cases like having a transform on a selectmenu, where the anchored element must be outside of the element. However, I think those cases are already broken under transforms.

I'm not very sure about this, especially for translation transforms.

Translations are commonly used for positioning purposes. Right now it's half-broken when used together with anchor positioning, and I feel like to should move it towards fully working instead of fully broken.

See also discussion at https://github.com/openui/open-ui/issues/779

vmpstr commented 9 months ago

selectmenu example seems particularly difficult since the menu is in the top layer, which means that it has to understand that the selectmenu itself can be affected by anything in its ancestor tree and it also must not have any anchor-scope ancestor, since then it would be broken.

Is it fair to say that there's a strong desire to use anchor positioning for selectmenu?

xiaochengh commented 9 months ago

Is it fair to say that there's a strong desire to use anchor positioning for selectmenu?

selectmenu is basically why we started working on anchor positioning at the beginning...