w3c / csswg-drafts

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

[css-scroll-snap-2] Should scroll-start-target specify alignment? #9012

Open DavMila opened 1 year ago

DavMila commented 1 year ago

The scroll-snap-2 spec lets authors specify "none" or "auto" for scroll-start-target. Would it be more useful to allow authors to specify how scrollers should align to these targets?

Perhaps keyword options similar to scrollintoview or scroll-snap-align would make sense.

flackr commented 1 year ago

I think we should consider a more generic mechanism for all operations which attempt to scroll a particular fragment into view. E.g. similar to how scroll-behavior sets the default behavior (smooth or instant, see example) and can be overridden by the scrollintoview behavior.

When there is a specified scroll-snap-align value we should be using that alignment, as best case we will scroll to that alignment anyways, but worst case scroll snap may move away from the scrolled to element due to another snap point being closer to the scroll position.

So putting all of this together, I think this might be something like, scroll-align: [normal | snap]? [ start | end | center ]{1,2}

Where this specifies the alignment to be used for scrolling operations targeting the element (scroll-start, anchor navigation, etc).

And then specifying a non-none value for scroll-snap-align could set the scroll align type to snap?

DavMila commented 1 year ago

I think a generic mechanism sounds like a good idea. And having scroll-snap-align set scroll-align makes sense.

Could you elaborate a little on the proposal for scroll-align's syntax: why is the first option needed given that scroll-snap-align will override scroll-align? Or are there cases where it would/should not override?

flackr commented 1 year ago

Could you elaborate a little on the proposal for scroll-align's syntax: why is the first option needed given that scroll-snap-align will override scroll-align? Or are there cases where it would/should not override?

The normal option allows you to specify an alignment for scroll targeting operations (e.g. linked to an element or scroll-start without making the element a snap point.

Technically we don't need that if we still have scroll-snap-align as a separate property but it's a bit awkward to have two properties attempting to determine the scroll-align alignment. By making scroll-align capable of handling snap alignment, scroll-snap-align becomes an alias for setting scroll-align and internally we only need to track the scroll-align value.