[scroll-animations-1] Default axis based on `overflow`

[fantasai]

Currently we default to the block axis. Would it make sense to default to whichever axis is scrollable, if only one of them is, and otherwise to the block axis?

[bramus]

This may be a bit too much magic going on I think.

Some things that come to mind:

• With automatic detection, this could mean that a perfectly working scroll-driven animation suddenly stops working due to some margin bleeding out of an element down in the tree as it causes the scroller to scroll on the other axis as well.
• I guess this would require an extra layout pass to determine which axis is overflowing?
• Looking at specs like scroll snapping, the axis in scroll-snap-type is mandatory instead of being auto-derived from overflow (which it could, right?). For consistency, best to keep things similar.

[fantasai]

@bramus I should have clarified, this would be based on the computed value of overflow, i.e. if overflow is auto or scroll in only one axis, we use that axis, and otherwise we default to the block axis.

[bramus]

Ah, that makes things less complicated indeed :)

I currently don’t have an explicit opinion on this, but also no compelling argument in one of both directions …

[flackr]

Defaulting based on computed overflow style seems reasonable to me. In practice, does this mean we need an auto value which does this bit of magic?

[ydaniv]

yep, +1 on a magical auto in cases where the scrollable direction is obvious. I assume in these cases the other direction will be overflow: clip'd

[jonjohnjohnson]

@ydaniv

I assume in these cases the other direction will be overflow: clip'd

In the other direction, clip computes to hidden, because scroll containers.