[css-scroll-snap-1] Alignment when scrolling to an element with scroll-snap-align

[flackr]

css-scroll-snap-1 6.2 Choosing Snap Positions says the following:

If a page is navigated to a fragment that defines a target element (e.g. one that would be matched by :target, or the target of scrollIntoView()), and that element defines some snap positions, the user agent must snap to one of that element’s snap positions if its nearest scroll container is a scroll snap container. The user agent may also do this even when the scroll container has scroll-snap-type: none.

While working on this, the question came up of how to respect the alignment if the developer provided one. E.g. if the developer specifies a block alignment:

target.scrollIntoView({block: "end"});

What should we do if the target element has a non-none scroll-snap-align:

• Per the above spec text, if its nearest scroll container is a scroll snap container, we must honor the scroll-snap-align value. This seems reasonable as not doing so could result in the element not being visible. E.g. see degenerate case mentioned in https://github.com/w3c/csswg-drafts/issues/9012#issuecomment-1749344005
• If the nearest scroll container is not a scroll snap container, it would seem like we should use the specified alignment, but we don't have any way to tell whether an alignment was actually specified as by the cssom-view spec, if either block or inline aren't specified they are initialized to their default values of "start" and "nearest". As such, we don't differentiate whether an alignment was specified so if a UA uses the scroll-snap-align alignment it seems like it would have to always override the javascript provided alignment.

Having a CSS value override the JS one, especially when it's optional, seems like it runs counter to developer expectations - e.g. confusion around why the provided alignment wasn't used.

Another concern is that currently scrolling to a fragment also specifically invokes Scroll target into view, with behavior set to "auto", block set to "start", and inline set to "nearest" so it currently has a specified alignment, even though the developer did not provide it.

TLDR; There are a few questions around this space:

1. If we want to allow the developer to override the alignment, we probably need to have default values of "auto" which can then take the value from the scroll-snap-align value if specified, and otherwise fall back to defaults.
2. If we do want to allow the developer to override the alignment, then we also should update the scrolling to a fragment algorithm to pass in overridable "auto" values.
3. Can we make the optional "The user agent may also do this" part mandatory? This optional behavior is currently tested by scroll-target-align-001.html and scroll-target-align-002.html which results in interop 2022 failures as it's not implmented in chrome or safari. We could also relax the tests to allow not doing it, but it seems like it would be better if the behavior was consistent.

[skobes-chromium]

Small correction - the interop 2022 failures are scroll-target-snap-001.html and scroll-target-snap-002.html. These are snap containers (with proximity snapping). Chrome gives precedence to (default) ScrollIntoViewOptions over (explicit) scroll-snap-align. But on this point I observe that the Scroll Snap spec is in contradiction to the CSSOM View spec (re. how to "scroll a target into view"); we can't satisfy them both as written.

The tests scroll-target-align-001.html and scroll-target-align-002.html are also failing in Chrome but not tagged with interop 2022. These are the ones testing what the Scroll Snap spec declares to be optional behavior around honoring scroll-snap-align in NON-snapping containers (scroll-snap-type: none).