[csswg-drafts] [css-scroll-snap-1] Alignment when scrolling to an element with scroll-snap-align (#9576)

flackr has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-scroll-snap-1] Alignment when scrolling to an element with scroll-snap-align ==
[css-scroll-snap-1 6.2 Choosing Snap Positions](https://drafts.csswg.org/css-scroll-snap-1/#choosing) 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](https://drafts.csswg.org/selectors-4/#target-pseudo), or the target of [scrollIntoView()](https://drafts.csswg.org/cssom-view-1/#dom-element-scrollintoview)), and that element defines some [snap positions](https://drafts.csswg.org/css-scroll-snap-1/#scroll-snap-position), the user agent must [snap](https://drafts.csswg.org/css-scroll-snap-1/#scroll-snap) to one of that element’s snap positions if its nearest [scroll container](https://drafts.csswg.org/css-overflow-3/#scroll-container) is a [scroll snap container](https://drafts.csswg.org/css-scroll-snap-1/#scroll-snap-container). The user agent may also do this even when the scroll container has [scroll-snap-type: none](https://drafts.csswg.org/css-scroll-snap-1/#propdef-scroll-snap-type).

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:
```js
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](https://drafts.csswg.org/css-overflow-3/#scroll-container) is a [scroll snap container](https://drafts.csswg.org/css-scroll-snap-1/#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](https://drafts.csswg.org/css-overflow-3/#scroll-container) is not a [scroll snap container](https://drafts.csswg.org/css-scroll-snap-1/#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](https://drafts.csswg.org/cssom-view/#dom-element-scrollintoview) to their [default values of "start" and "nearest"](https://drafts.csswg.org/cssom-view/#dictdef-scrollintoviewoptions). 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](https://html.spec.whatwg.org/#scrolling-to-a-fragment) also specifically invokes [Scroll target into view](https://drafts.csswg.org/cssom-view/#scroll-a-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](https://html.spec.whatwg.org/#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](https://github.com/web-platform-tests/wpt/blob/master/css/css-scroll-snap/scroll-target-align-001.html) and [scroll-target-align-002.html](https://github.com/web-platform-tests/wpt/blob/master/css/css-scroll-snap/scroll-target-align-002.html) which results in [interop 2022 failures](https://wpt.fyi/results/css/css-scroll-snap?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&view=interop&q=label%3Ainterop-2022-scrolling) 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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9576 using your GitHub account


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

Received on Wednesday, 8 November 2023 21:10:49 UTC