[csswg-drafts] [css-scroll-snap-1] Improve or clarify nested snap behaviors (#9187)

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

== [css-scroll-snap-1] Improve or clarify nested snap behaviors ==
## Friction to leaving larger than viewport area

[example 8](https://drafts.csswg.org/css-scroll-snap-1/#example-8f4980a0) suggests that there should be some resistance when leaving a snap area larger than the viewport (e.g. from section 1 to section 2).

> However, if the container is scrolled such that the area no longer fully fills the viewport in an axis, the area resists outward scrolling until it is scrolled sufficiently to trigger snapping to a different [snap position](https://drafts.csswg.org/css-scroll-snap-1/#scroll-snap-position).

This seems like good behavior however it's not clear that it's specified by any normative behavior and it seems too easy on all browsers today to accidentally scroll into the next section.

## Prefer descendant snap point when visible

[example 9](https://drafts.csswg.org/css-scroll-snap-1/#example-e9209b74) suggests that the intention is to allow scrolling freely within larger sections while still snapping when smaller nested sections are encountered.

The normative text [5.2.2.](https://drafts.csswg.org/css-scroll-snap-1/#snap-overflow),
> If the [snap area](https://drafts.csswg.org/css-scroll-snap-1/#scroll-snap-area) is larger than the [snapport](https://drafts.csswg.org/css-scroll-snap-1/#scroll-snapport) in a particular axis, then any scroll position in which
> * the [snap area](https://drafts.csswg.org/css-scroll-snap-1/#scroll-snap-area) covers the [snapport](https://drafts.csswg.org/css-scroll-snap-1/#scroll-snapport), and
> * the distance between the geometrically previous and subsequent otherwise-valid [snap positions](https://drafts.csswg.org/css-scroll-snap-1/#scroll-snap-position) in that axis is larger than size of the [snapport](https://drafts.csswg.org/css-scroll-snap-1/#scroll-snapport) in that axis,
>
> is a valid [snap position](https://drafts.csswg.org/css-scroll-snap-1/#scroll-snap-position) in that axis.

I've created a page similar to [example 9](https://drafts.csswg.org/css-scroll-snap-1/#example-e9209b74) from [css-scroll-snap 5.2.2.  Snapping Boxes that Overflow the Scrollport](https://drafts.csswg.org/css-scroll-snap-1/#snap-overflow), where we have nested sections within section 2 at https://flackr.github.io/web-demos/css-scroll-snap/nested/sections.html

The second requirement seems like it may not correctly capture the intention - for example when scrolling within section 2 before we reach section 2.1 example 9 would suggest we should prefer either being before section 2.1 or snapped to section 2.1, however the spec text would suggest that since the distance between the previous snap point (section 1) and the subsequent snap point (section 2.1) is larger than the size of the viewport that we still consider arbitrary scroll within section 2 (with section 2.1 in view) to be snap aligned. Browsers indeed seem to not force snapping to section 2.1 until it's very near the top.

If my understanding of the spirit of the requirement is correct, I think that this [body scroll snap region example](https://flackr.github.io/web-demos/css-scroll-snap/nested/body.html) (based on a developer request in [crbug.com/1420439](https://bugs.chromium.org/p/chromium/issues/detail?id=1420439)) resolves the developer issue by having the `<body>` (an ancestor of the mandatory scroll snap regions) also be a snap region.

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


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

Received on Monday, 14 August 2023 20:53:12 UTC