Closed Bug 1373835 Opened 7 years ago Closed 5 years ago

Implement scroll-snap-align property

Categories

(Core :: CSS Parsing and Computation, enhancement, P3)

53 Branch
enhancement

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox57 --- wontfix
firefox68 --- fixed

People

(Reporter: sebo, Assigned: hiro)

References

(Blocks 2 open bugs, )

Details

(Keywords: dev-doc-complete)

Attachments

(10 files, 1 obsolete file)

47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
The latest CSS Scroll Snap spec. defines a scroll-snap-align property, which specifies the box's snap position as an alignment of its snap area within the snapport.

This property should be implemented accordingly.

Sebastian
Priority: -- → P3
Blocks: 1373833
Depends on: 1528834
Depends on: 1312163
Blocks: 1373832
Assignee: nobody → hikezoe
Status: NEW → ASSIGNED

The right top element is positioned at left:1000px and its width is 600px and
the width of the largest element in the content is 2100px. So if the browser
window width (precisely documentElement clientWidth) is greater than 1100px, the
right top element is not suitable for scroll-snap-align:start, thus some test
cases fail.

Given the test description is mentioning scrollBy, scrollBy should be used
there.

Depends on D21623

From the spec [1];

Using the scroll-snap-type property on the relevant scroll container, the
author can request a particular bias for the scrollport to land on a snap
position after scrolling operations (including programmatic scrolls such
as the scrollTo() method).

The target here are functions exposed in web contents other than
Element.scrollIntoView which will be changed in the next commit.

[1] https://drafts.csswg.org/css-scroll-snap-1/#overview

Depends on D21624

https://drafts.csswg.org/css-scroll-snap-1/#scroll-snap-align

The main logic here is basically same as the old scroll snap implementation,
just iterating over all descendant elements in the scroll container and collect
snap positions. The differences are;

  1. the snap positions are specified based on descendant elements instead of
    points
  2. the snap positions are able to be specified by block or inline keywords
    so that we also need to care the element flow.
    more test cases for this are coming in the next commit
  3. the target rect is calculated by nsLayoutUtils::TransformFrameRectToAncestor
    which means transform is already taken account into it (we have a bug for
    the old scroll snap, it's bug 1218745)
    some of web platform tests will be added in a subsequent commit

Some of test cases in overflowing-snap-areas.html that accidentally have
passed start failing with this change, all of them will be passed with
subsequent changes in these commit series.

Depends on D21627

The snap alignment position of the target element is the top left of the target
and the position is located out of scroll port (top: -100px, left: -100px).
Even so we try to snap a position as much as possible.

From the spec [1];
If a snap position is unreachable as specified, such that aligning to it would
require scrolling the scroll container’s viewport past the edge of its
scrollable overflow region, the used snap position for this snap area is the
position resulting from scrolling as much as possible in each relevant axis
toward the desired snap position.

[1] https://drafts.csswg.org/css-scroll-snap-1/#unreachabLe

Depends on D21630

As for scrolling on the compositor we don't cull out them since we don't know
the final snapport rect at the time when we send the information about
snapping to the compositor. And we will handle it for APZ in bug 1531589.

https://drafts.csswg.org/css-scroll-snap-1/#snap-scope

Depends on D21632

Jonathan, would you mind taking a look at attachment 9047570 [details] and attachment 9047571 [details] in terms of RTL? Especially about https://phabricator.services.mozilla.com/D21628#612388 .

Flags: needinfo?(jfkthame)
Attachment #9047571 - Attachment is obsolete: true
Flags: needinfo?(jfkthame)
Pushed by hikezoe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a85948af4c36
Make the largest element wider. r=botond
https://hg.mozilla.org/integration/autoland/rev/9d201f2c3279
Use scrollBy instead of scrollTo in a test in scrollTo-scrollBy-snaps.html. r=botond
https://hg.mozilla.org/integration/autoland/rev/ab5811341092
Enable scroll snap for programatic scrolls. r=botond
https://hg.mozilla.org/integration/autoland/rev/2e7cebd9ed56
Enable scroll snap for Element.scrollIntoView. r=botond
https://hg.mozilla.org/integration/autoland/rev/15f5d6a74247
Make ComputeScrollSnapInfo a private method of ScrollFrameHelper. r=botond
https://hg.mozilla.org/integration/autoland/rev/bd7f3fa1efbd
Implement scroll-snap-align. r=botond,jfkthame
https://hg.mozilla.org/integration/autoland/rev/d4682a804eba
Add a test case that the snap target element is transformed. r=botond
https://hg.mozilla.org/integration/autoland/rev/29466eb6ee25
Add a test case for unreachable snap positions. r=botond
https://hg.mozilla.org/integration/autoland/rev/335307e3cca3
Make positions in the range that the element covers the snapport valid snap positions. r=botond
https://hg.mozilla.org/integration/autoland/rev/11ce2cf9d66c
Cull out elements which will be invisible in the snapport for programatic scrolls. r=botond
Regressions: 1544325
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/16484 for changes under testing/web-platform/tests

This is documented and a note added to the 68 release notes https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-snap-align

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: