2052099 - Implement Chrome compatible overflow snap area behavior

Status: ASSIGNED

(Core :: Layout: Scrolling and Overflow, task, P3)

Description

[Hiroyuki Ikezoe (:hiro)]

While writing the spec text to reflect the spec resolution for https://github.com/w3c/csswg-drafts/issues/9187, Claude realized me that Chrome hasn't yet implemented the option 7 that the CSSWG agreed on as a resolution, rather the approach what Chrome has implemented and has shipped is not including the option 7.

overflowing-snap-areas-nested.html is the only one wpt exercising the option 7 case, if Chrome has implemented option 7, the test should have failed, but as per the result on wpt.fyi, it's been passing.

I'd say implementing option 7 will be risky for us, I'd rather think we should align with the current Chrome's behavior now, then later we can change it aligning with Chrome's change.

Note that the Chrome's implementation was done in https://chromium-review.googlesource.com/c/chromium/src/+/4799170 .

I've written the spec text to reflect the Chrome's behavior: https://github.com/hiikezoe/csswg-drafts/commit/9e8d65931009717e5200cf21e8569ecda1506f21

With that I am going to move the patches on bug 1942690 to here in this bug.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 2052099 - Add ScrollRange::mFragments to represent smaller chunks divided by subsequent snap areas. r?botond,ajakobi

The reason we use std::list for the fragments is a new fragment is
often inserted anywhere.

Comment 2

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 2052099 - Fixup m[X|Y]RangeWiderThanSnapport to conform to the rules [1]. r?botond,ajakobi

My interpretation of the rules is:

1. if there's a snap target element lying on top of another snap target
   element which is larger than the snapport, the area covered by the upper
   snap target is excluded from the overflow snap target element rule [2]:

If the snap area is larger than the snapport in a particular axis,
then any scroll position in which

• the snap area covers the snapport, and
• the distance between the geometrically previous and subsequent
  otherwise-valid snap positions in that axis is larger than size of
  the snapport in that axis,
  is a valid snap position in that axis.

2. and even if an area divided by the excluded area is now smaller than the
   snapport, the divided area is a new snap target area

Now in this change divided areas are stored into mFragments.

[1] https://github.com/w3c/csswg-drafts/issues/9187
[2] https://drafts.csswg.org/css-scroll-snap-1/#snap-overflow

Comment 3

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 2052099 - Snap to the covering position nearest the destination across all overflowing snap areas. r?botond,ajakobi

When more than one snap area is wider than the snapport on an axis (for
example nested oversized areas), ProcessSnapOverflowForAxis used to stop at
the first range that could cover the snapport. Instead, evaluate every
overflowing range and choose the covering position closest to the scroll
destination.

ScrollSnapRange::FindNearestSnapPoint now walks the fragments left after
excluding the areas of overlapping snap targets (ScrollSnapRange::mFragments)
and returns the nearest position at which the area still covers the snapport.
When a fragment is narrower than the snapport it cannot contain it, so the
covering position within that fragment is placed according to the snap area's
scroll-snap-align, resolved to the physical axis via PhysicalCoverAlign, to
match Chromium.

Add overflowing-snap-areas-nested-alignment.html covering start/center/end
alignment of the covering position in a sub-snapport gap between nested areas.