Intent to Ship: CSS Scroll Snap

1069 views
Skip to first unread message

Yunjia (Sandra) Sun

unread,
May 10, 2018, 2:46:54 PM5/10/18
to blink-dev

Intent to Ship: CSS Scroll Snap


Contact emails

suny...@chromium.org, maj...@chromium.org


Spec

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


Summary

CSS scroll snap introduces snap positions as a way to enforce the scroll offsets that a scroll container’s visual viewport may end at after a scrolling operation has completed. The term scrolling operation refers to any user input scrolling such as touch, wheel scrolling, or scrollbar dragging.


We plan to do a phased roll out with the bulk of features in this initial phase. This intent is for the initial phase.


Initial Phase - In M68

We plan to ship a feature set that is comparable with what Safari is shipping. This includes:

  • Snapping in both mandatory and proximity modes for gesture (including flings), wheel, and scrollbar dragging.

  • Supports snapping on both fast (impl)  and slow (main) paths.

  • Additionally we support snapping programmatic scrolls (scrollBy, ScrollTo, etc.) and take into account the visibility requirements.


See the table in interop section for more details on how we compare to Safari and interop among all vendors. There are few blocking issues that we plan to address before shipping.



Subsequent Phases - TBD

We plan to implement the following features and ship them once ready.

  • Snap at keyboard arrow keys.

  • Full support for scrollbars (including arrow buttons).

  • Correctly considering the elements larger than viewport.

  • Polishing various animation curves.

  • Support scroll-snap-stop.


Link to “Intent to Implement” blink-dev discussion

Intent to Implement: CSS Scroll Snap Points


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Demo links

https://webkit.org/demos/scroll-snap/

https://syj10.github.io/scroll-snap-demo.html

https://syj10.github.io/viewport.html

BlinkOn9 presentation


Risks


Interoperability and Compatibility Risk

Edge and Firefox are shipping the old version of the specification (based on points), but working group has accepted the current level-1 specification which is based on box alignments model. As Edge and Firefox are shipping the old model but we are shipping the new one, there is a risk of sites using the old syntax and not working interop. However, based on the status, the usage of the new spec (scroll-snap-align) is significantly higher than that of the old spec (scroll-snap-points, scroll-snap-coordinate, scroll-snap-destination)



  Firefox: Ships the old spec unprefixed and committed to implementing new one.

Edge: Ships a variation of old spec prefixed and committed to implementing new one .

  Safari: Ships most of the new level-1 spec.

  Web developers: Positive


Details of our coverage compared to Safari:



Mandatory/Proximity

Visibility requirement

Larger than snapport

Must-stop

Programmatic scrolls

Supported Inputs

Notes

Chrome


Yes

Yes

No

No

Yes

touch,

touchpad, wheel, scrollbar

No keyboard, scrollbar is only dragging.

Safari

Yes

No

No

No

No

touch,

touchpad, wheel

No keyboard or  scrollbar.




Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

No


Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

No


Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

No


Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

There may be a need for documentation specifically explaining how deprecated syntax can be migrated to the new one.


Is this feature fully tested by web-platform-tests?

We have been upstreaming tests as part of our implementation. And here are the tests for the parts already implemented.

https://wpt.fyi/css/css-scroll-snap


OWP launch tracking bug

crbug.com/497851


Entry on the feature dashboard

https://www.chromestatus.com/features/5721832506261504

Sandra Sun

unread,
May 10, 2018, 3:30:22 PM5/10/18
to blin...@chromium.org, Majid Valipour

Chris Harrelson

unread,
May 10, 2018, 4:17:43 PM5/10/18
to Yunjia (Sandra) Sun, blink-dev
(I'm assuming this thread is replaced by the newer one, will respond on that.)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a7924071-10db-4eb5-b6d6-690b2b855b6b%40chromium.org.

Chris Harrelson

unread,
May 10, 2018, 4:25:48 PM5/10/18
to suny...@chromium.org, blink-dev, Majid Valipour
LGTM1 to ship "initial phase".

I observed that all of the use-counters are extremely small (largest is 0.000013%), so I don't anticipate any immediate risk of breaking sites.

Regarding "Correctly considering the elements larger than viewport", what is the limitation? Is this an area where we might end up with a compat issue when fixed?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Majid Valipour

unread,
May 10, 2018, 6:04:11 PM5/10/18
to Chris Harrelson, suny...@chromium.org, blink-dev

I observed that all of the use-counters are extremely small (largest is 0.000013%), so I don't anticipate any immediate risk of breaking sites.

That is also our evaluation. Also shipping the new specification does not affect any site that is using the old syntax. 
 
Regarding "Correctly considering the elements larger than viewport", what is the limitation? Is this an area where we might end up with a compat issue when fixed?

Basically the requirement in the specification is that when a snap area is larger than its snap container the UA should allow the user to 
freely pan around and not snap at the end (relevant spec section). Our implementation currently snaps as does Safari. So once we 
implement this, Chrome will not snap in cases where it would had snapped before favoring better UX.

I don't expect this to lead to any major compat issues. 

Majid 
 

Florian Rivoal

unread,
May 10, 2018, 10:50:18 PM5/10/18
to Majid Valipour, Chris Harrelson, suny...@chromium.org, blink-dev
I welcome and support this intent to ship.

I would however encourage you to include support for elements larger than the snap-port from the start, as otherwise pages may become unusable on devices with a smaller screen than anticipated by the author. This is not a problem of compatibility with other browsers, but it may be a limit to adoption of the feature for authors who notice, and may make pages difficult or impossible to use on some devices when authors don't. The ability to handle this kind of situation was one of the motivations for switching from the old model to the new one.

Also, I don't know if you already do this or not, but please make sure that when you support scroll-padding, you support its effects not just on scroll-snapping but on all kinds scrolling, as specified. Otherwise, there is a forward compat risk: people sometimes use JavaScript to correct the scroll position after following a link with an anchor or a call to focus() or similar scroll-inducing actions, to make sure that any sticky header or the like isn't covering the content you were scrolling to. scroll-padding deals with the same problem declaratively, so people who have that piece of JS and want to introduce scroll-padding should turn the JS off when scroll-padding is supported. However, if initially scroll-padding only applies to snapping and not to other types of scrolling, then authors are likely to leave both on. This would break pages when you later turn it on, which may prevent us from ever turning it on, which would be bad.

As for tests, thanks for submitting some. I think we need many more, and intent to contribute some myself.

—Florian
CSS-WG member

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Yoav Weiss

unread,
May 11, 2018, 8:46:05 AM5/11/18
to Florian Rivoal, Majid Valipour, Chris Harrelson, suny...@chromium.org, blink-dev
Is the WebKit implementation correctly considering elements larger than the viewport? If so, what happens if we ship a version which does not?
Regarding the subsequent phases, are they involving syntax changes? Will they be feature detectable? Or will developers be expected to use fallbacks to support multiple shipping models for this?

Florian Rivoal

unread,
May 11, 2018, 9:08:46 AM5/11/18
to Yoav Weiss, Majid Valipour, Chris Harrelson, suny...@chromium.org, blink-dev


> On May 11, 2018, at 21:45, Yoav Weiss <yo...@yoav.ws> wrote:
>
> Is the WebKit implementation correctly considering elements larger than the viewport?

Not as far as I can tell.

> If so, what happens if we ship a version which does not?

If you both don't, you both suck on pages with smaller viewports than expected. If you ship something that correctly considers elements larger than the viewport while Safari doesn't, pages with small elements in big viewports will behave just the same, and pages with big elements in small viewport will be usable in Chrome and not in Safari, putting pressure on them to upgrade.

I don't think there is a large risk of being stuck in the bad behavior due to web compat, since that would mean that people are designing pages were they depend on content being impossible to reach in browsers that support scroll-snapping while being reachable in browsers that don't. That does not sound terribly likely, so long term, I am not worried.

My request about supporting this from the start is because otherwise, from an author point of view, the best thing to do might be to not use the feature at all, as it may make your page unusable on some devices.

—Florian

Yoav Weiss

unread,
May 11, 2018, 9:34:33 AM5/11/18
to Florian Rivoal, Majid Valipour, Chris Harrelson, suny...@chromium.org, blink-dev
From what you describe, until all vendors ship the behavior that snaps larger-than-viewport elements, developers won't be able to use the feature for any element which might be larger than the viewport (for any possible viewport on the non-supporting platforms). I'm also guessing there won't be a way to feature detect that. Is there a reasonable fallback for those cases?

Majid Valipour

unread,
May 11, 2018, 2:13:23 PM5/11/18
to Florian Rivoal, Chris Harrelson, suny...@chromium.org, blink-dev


On Thu, May 10, 2018 at 10:50 PM Florian Rivoal <flo...@rivoal.net> wrote:
[...] Also, I don't know if you already do this or not, but please make sure that when you support scroll-padding, you support its effects not just on scroll-snapping but on all kinds scrolling, as specified. Otherwise, there is a forward compat risk: people sometimes use JavaScript to correct the scroll position after following a link with an anchor or a call to focus() or similar scroll-inducing actions, to make sure that any sticky header or the like isn't covering the content you were scrolling to. scroll-padding deals with the same problem declaratively, so people who have that piece of JS and want to introduce scroll-padding should turn the JS off when scroll-padding is supported. However, if initially scroll-padding only applies to snapping and not to other types of scrolling, then authors are likely to leave both on. This would break pages when you later turn it on, which may prevent us from ever turning it on, which would be bad.


scroll-padding and scroll-margin will be supported on scrollIntoView and focus (relevant tests: 12). So the specific  usecases you mention should be fine.
 
As for tests, thanks for submitting some. I think we need many more, and intent to contribute some myself.

We have some key aspects covered and will continue to add more tests as we implement more features. It is great that you plan to add more tests too.
Here is an issue to tracking adding more tests on our end. Feel free to leave a comment there on ideas where we should prioritize our effort  in testing. 

Majid

Majid Valipour

unread,
May 11, 2018, 2:21:16 PM5/11/18
to Yoav Weiss, Florian Rivoal, Chris Harrelson, suny...@chromium.org, blink-dev
Here, I am going to focus on concerns related to shipping in two phases in particular the issues related to larger-than-snapport element targets.

On Fri, May 11, 2018 at 9:34 AM Yoav Weiss <yo...@yoav.ws> wrote:
From what you describe, until all vendors ship the behavior that snaps larger-than-viewport elements, developers won't be able to use the feature for any element which might be larger than the viewport (for any possible viewport on the non-supporting platforms). I'm also guessing there won't be a way to feature detect that. Is there a reasonable fallback for those cases?

Only 'scroll-snap-stop' involves a syntax change and can be feature detected.
The rest don't involve any syntax changes. The fallback is to simply disable snapping and use any previous solution that was applicable.
 
On Fri, May 11, 2018 at 3:08 PM Florian Rivoal <flo...@rivoal.net> wrote:


> On May 11, 2018, at 21:45, Yoav Weiss <yo...@yoav.ws> wrote:
>
> Is the WebKit implementation correctly considering elements larger than the viewport?

Not as far as I can tell.
 
This is what our testing suggests as well.
 
> If so, what happens if we ship a version which does not?

If you both don't, you both suck on pages with smaller viewports than expected. If you ship something that correctly considers elements larger than the viewport while Safari doesn't, pages with small elements in big viewports will behave just the same, and pages with big elements in small viewport will be usable in Chrome and not in Safari, putting pressure on them to upgrade.

I don't think there is a large risk of being stuck in the bad behavior due to web compat, since that would mean that people are designing pages were they depend on content being impossible to reach in browsers that support scroll-snapping while being reachable in browsers that don't. That does not sound terribly likely, so long term, I am not worried.

I agree. This is not likely to create a web-compat issue.

My request about supporting this from the start is because otherwise, from an author point of view, the best thing to do might be to not use the feature at all, as it may make your page unusable on some devices.

I think that is a fair assessment and something that we should consider carefully.

Shipping phase 1 alone means that authors have to carefully consider their content and site design before applying snapping.
In particular, sites with following usecase should not use scroll snap at the moment:
  • If they have ha larger-than-snapport snap targets. If they use mandatory snapping in this this case, once a user scroll the target into view and let go to complete the scroll operation we snap which may not be desirable.
  • If they heavily depends on keyboard scrolling and want snapping on it. In this case, keyboard scrolling does not snap.
Note that this is the case today with Safari implementation. These usecases will have to wait for Chrome and Safari to ship the missing features.

To summarize, I believe the trade off is:
  • Ship an initial version matching safari behavior now which benefits current users of snap points. This risks authors that cannot use it in its current form to not adopt or worse use incorrectly leading to subpar behavior which later has to be worked around by browser sniffing.
  • Wait to ship the more complete version. Risks delaying the benefit and still suffers from the browser sniffing issue to handle the behavior currently shipping in Safari.

Our assessment was that shipping initial version now provides enough benefits to justify the risk given that Safari is shipping these already.
We also intend to ship all other features in the span of 1 to 2 releases which should reduce the risk.
I can imagine for us to introduce ways to make the missing feature detectable to avoid browser sniffing if it becomes necessary.


Majid

fla...@google.com

unread,
May 11, 2018, 3:59:40 PM5/11/18
to blink-dev, yo...@yoav.ws, flo...@rivoal.net, chri...@chromium.org, suny...@chromium.org
On Friday, May 11, 2018 at 2:21:16 PM UTC-4, Majid Valipour wrote:
Here, I am going to focus on concerns related to shipping in two phases in particular the issues related to larger-than-snapport element targets.

On Fri, May 11, 2018 at 9:34 AM Yoav Weiss <yo...@yoav.ws> wrote:
From what you describe, until all vendors ship the behavior that snaps larger-than-viewport elements, developers won't be able to use the feature for any element which might be larger than the viewport (for any possible viewport on the non-supporting platforms). I'm also guessing there won't be a way to feature detect that. Is there a reasonable fallback for those cases?

Only 'scroll-snap-stop' involves a syntax change and can be feature detected.
The rest don't involve any syntax changes. The fallback is to simply disable snapping and use any previous solution that was applicable.

FWIW, this can be feature detected by constructing a small offscreen scroller (say 100x100) and putting an element larger than that inside of it (say 200x200) with mandatory snapping and testing whether you can scroll to an offset within the element (e.g. 10, 10).

Rick Byers

unread,
May 11, 2018, 4:26:22 PM5/11/18
to Robert Flack, blink-dev, Yoav Weiss, Florian Rivoal, Chris Harrelson, Sandra Sun
Thanks for the input Florian (and all your work on the spec of course)!  Talking with Majid, I tend to agree that the benefits of shipping this part now, outweighs the risks.  In particular, the forward-compat risk of addressing these issues seems trivial.  There's some risk that a developer might have trouble adopting the final version without relying on a UA string check if they depend on keyboard support or larger-than-viewport elements.  But that risk exists anyway with the Safari implementation already having shipped, and worst-case a blacklist UA check (fallback on Chrome below version 70 or whatever) isn't that bad (in contrast to generic UA string checks which attempt to reason about future versions or unknown browsers).

On the benefits side, we know the web is really suffering for lack of this feature - janky image carousels are a big "tell" in PWAs and we've had major partners clamoring for us to ship snap points for years.  We still shouldn't ship anything that's not ready, but this "snap points without keyboard and larger-than-viewport element support" feature sounds like it's ready and highly useful to me (eg. will be strictly better than current approaches the partner use cases I'm aware of).

Sandra/Majid, can you provide links to the bugs tracking the remaining work you intend to do post-ship here?  If we're going with an incremental launch, then it's obviously important that getting fully spec compliant remains a priority for the team (along with driving adoption and supporting implementations in other engines as usual). 

Florian, what do you think?  Assuming the timeframe for shipping the final spec-compliant version is the same either way (which it should be), how would you evaluate the benefit to the web of delaying shipping this functional subset? 

BTW, I believe all the UseCounter numbers in this thread are meaningless - they reflect only usage that occurred for users with a flag enabled (we don't count usage of CSS properties which the parser does not recognize as valid - which is the case when experimental features are disabled).  But I also don't think they're really relevant to the discussion - usage of the old syntax should have no bearing on the interop/compat risks of the new syntax.  And, since we believe all sites compatible with Safari will also be compatible with Chrome's implementation, the current usage of the new syntax does not pose a compat concern.  As soon as we enable the flag, we'll get real new-syntax UseCounter data.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Yunjia (Sandra) Sun

unread,
May 11, 2018, 4:58:15 PM5/11/18
to Rick Byers, Robert Flack, blink-dev, Yoav Weiss, Florian Rivoal, Chris Harrelson
Thanks Rick! Here are the bugs representing the tasks remaining to make it spec-compliant, after shipping the initial phase. And all the bugs related to CSSScrollSnap, big or small, are blocking this issue.

Ojan Vafai

unread,
May 11, 2018, 6:39:04 PM5/11/18
to Yunjia (Sandra) Sun, Rick Byers, Robert Flack, blink-dev, Yoav Weiss, Florian Rivoal, Chris Harrelson

Florian Rivoal

unread,
May 11, 2018, 10:06:56 PM5/11/18
to Rick Byers, Majid Valipour, Robert Flack, blink-dev, Yoav Weiss, Chris Harrelson, Sandra Sun
On May 12, 2018, at 5:25, Rick Byers <rby...@chromium.org> wrote:

Florian, what do you think?  Assuming the timeframe for shipping the final spec-compliant version is the same either way (which it should be), how would you evaluate the benefit to the web of delaying shipping this functional subset? 

I think Majid and your assessment is fair. There is a risk, but it is not a forward compat risk, so even it what you ship early turns out to cause issues more often than expected, you can always ship the full solution on top and solve the issues.

I think in practice, the risk is something is one of the following, or both combined:
* The web sites works well with the content that the author tested with, but in the live version, content is not static but pulled from a database, and is sometimes bigger (more text, bigger images) than the author expected.
* The author has made a responsive website (who doesn't these days), so the design works on desktop and mobile. But maybe inbetween sizes are handled poorly because the author forgot to test on small laptops, or something like that.

If the author detects these, then they'll just skip using it for now, and we're not worse off that if Chrome had not shipped yet.

If the author doesn't detect, some users will suffer. So I guess the main risk is a few disgruntled users switching browsers to either one that supports full-featured snapping (none yet), or one that doesn't have it at all. But if that happens, it will only be a few users. If it was affecting a lot of users, presumably web page authors would notice and do something about it.

Also, I think that following up relatively soon with the full spec compliant solution is also reasonably important to mitigate the risk that scroll-snap acquires a reputation for being that terrible thing you should not use because it makes sites unusable.

So there's a tradeoff, but I agree that as long as you don't leave it at that for years, shipping early without support for larger-than-viewport elements is probably a good way to go.

—Florian

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Florian Rivoal

unread,
May 11, 2018, 10:08:27 PM5/11/18
to Majid Valipour, Chris Harrelson, Sandra Sun, blink-dev

On May 12, 2018, at 3:13, 'Majid Valipour' via blink-dev <blin...@chromium.org> wrote:

scroll-padding and scroll-margin will be supported on scrollIntoView and focus (relevant tests: 12). So the specific  usecases you mention should be fine.


Excellent. In my mind that was the biggest forward compat risk, so as you addressed that correctly, we're good.

As for tests, thanks for submitting some. I think we need many more, and intent to contribute some myself.

We have some key aspects covered and will continue to add more tests as we implement more features. It is great that you plan to add more tests too.
Here is an issue to tracking adding more tests on our end. Feel free to leave a comment there on ideas where we should prioritize our effort  in testing. 

Thanks for the pointer. Not sure exactly when I'll be able to get to this, but I do plan on doing so. Stay tuned.

—Florian

Yoav Weiss

unread,
May 11, 2018, 11:47:07 PM5/11/18
to Florian Rivoal, Majid Valipour, Chris Harrelson, Sandra Sun, blink-dev
I agree with Rick's assessment that benefits of shipping early outweigh the risks, and the risks exist already due to Safari's implementation shipping.
flackr@'s feature detection technique may also help mitigate that risk, since UA sniffing is not the sole avenue for eventual compatibility. (blacklist UA check will not be possible for Safari once they support larger-than-viewport, since UA strings include no up-to-date version there) 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

fantasai

unread,
May 12, 2018, 9:35:44 AM5/12/18
to Majid Valipour, Florian Rivoal, Chris Harrelson, suny...@chromium.org, blink-dev
First of all, +1 to all of Florian's concerns.

Secondly, wrt scroll-padding, specifically:

On 05/11/2018 11:13 AM, 'Majid Valipour' via blink-dev wrote:
> On Thu, May 10, 2018 at 10:50 PM Florian Rivoal <flo...@rivoal.net <mailto:flo...@rivoal.net>> wrote:
>
> [...] Also, I don't know if you already do this or not, but please make sure that when you
> support scroll-padding, you support its effects not just on scroll-snapping but on all kinds
> scrolling, as specified. Otherwise, there is a forward compat risk: people sometimes use
> JavaScript to correct the scroll position ... which would be bad.
>
> scroll-padding and scroll-margin will be supported on scrollIntoView and focus (relevant tests: 1
> <https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/external/wpt/css/cssom-view/scrollIntoView-scrollPadding.html?sq=package:chromium>,
> 2
> <https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/external/wpt/css/cssom-view/scrollIntoView-scrollMargin.html>).
> So the specific usecases you mention should be fine.

It needs to also affect page-up/page-down operations (both via keyboard and via scrollbar UI).
This is among of the most important aspects of scroll-padding, from a "replace scrolljacking
workarounds" perspective. (The point is to mask out part of the scrollport from scrolling
operations that bring content into view, so that UIs that used fixed-positioned panels don't
end up hiding content when scrolling by page--currently pages handle this by adjusting the
scroll position with JS.)

It's harmful to ship support for scroll-padding without correctly supporting these cases,
since it makes @supports / .supports queries useless for detecting whether JS workarounds
are needed. The responsible options are to either fully support scroll-padding as specified,
or treat it as an unsupported property (disabled at parse time).

~fantasai

fantasai

unread,
May 12, 2018, 10:01:16 AM5/12/18
to Majid Valipour, Yoav Weiss, Florian Rivoal, Chris Harrelson, suny...@chromium.org, blink-dev
On 05/11/2018 11:21 AM, 'Majid Valipour' via blink-dev wrote:
> Here, I am going to focus on concerns related to shipping in two phases in particular the issues
> related to larger-than-snapport element targets.
>
> ...
>
> Our assessment was that shipping initial version now provides enough benefits to justify the risk
> given that Safari is shipping these already.
> We also intend to ship all other features in the span of 1 to 2 releases which should reduce the risk.
> I can imagine for us to introduce ways to make the missing feature detectable to avoid browser
> sniffing if it becomes necessary.

I think your points address any concern about forwards-compat / web-compat risks.

I don't think they address the user accessibility issue, though, which arises
when the author did not sufficiently think through what happens on smaller
screens and enabled, say, mandatory snapping.

(It may still be worth shipping and fixing that aspect later, but it is a
separate concern.)

~fantasai

fantasai

unread,
May 12, 2018, 10:41:43 AM5/12/18
to Majid Valipour, Yoav Weiss, Florian Rivoal, Chris Harrelson, suny...@chromium.org, blink-dev
On 05/11/2018 11:21 AM, 'Majid Valipour' via blink-dev wrote:
> Here, I am going to focus on concerns related to shipping in two phases in particular the issues
> related to larger-than-snapport element targets.
>
> ...
>
> Our assessment was that shipping initial version now provides enough benefits to justify the risk
> given that Safari is shipping these already.
> We also intend to ship all other features in the span of 1 to 2 releases which should reduce the risk.
> I can imagine for us to introduce ways to make the missing feature detectable to avoid browser
> sniffing if it becomes necessary.

Daniel Bratell

unread,
May 14, 2018, 10:40:23 AM5/14/18
to Majid Valipour, Yoav Weiss, fantasai, Florian Rivoal, Chris Harrelson, suny...@chromium.org, blink-dev
Much in this thread has been about elements larger than the
viewport/snapport and that the risk for that happening is not large. I
wonder (and I'm sure this is in some spec somewhere), what happens if you
zoom in so that elements become very large.

An image carousel was mentioned, and I can imagine someone zooming in to
look closer at an image. Won't that become larger than the snapport in
that case? What would happen with the scroll position?

/Daniel
--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

Majid Valipour

unread,
May 14, 2018, 11:27:59 AM5/14/18
to fantasai, Yoav Weiss, Florian Rivoal, Chris Harrelson, suny...@chromium.org, blink-dev
sunyunjia@ and I have a chat today specifically regarding accessibility concerns
here. If I understand it correctly, most user can pan around if they continue
their active scrolling operation (e.g., hold finger down) to delay the snapping.
This is bad and per previous discussions should be rare and already the case in
Safari. But I think the failure mode here will be much more problematic for any
person with motor or dexterity impairments for whom holding down the finger may
be impossible. 

We have decided to include this feature in our initial phase to ensure better
accessibility for everybody. This may lead to delay shipping scroll snap until 
M69 but it is the right thing to do here. Thanks for the feedback.

I like to continue this intent-to-ship thread with the additional change to
include "Correctly considering the elements larger than viewport" in the initial
phase.

Majid

Majid Valipour

unread,
May 14, 2018, 12:17:05 PM5/14/18
to fantasai, Florian Rivoal, Chris Harrelson, suny...@chromium.org, blink-dev
On Sat, May 12, 2018 at 9:35 AM fantasai <fantasa...@inkedblade.net> wrote:
First of all, +1 to all of Florian's concerns.

Secondly, wrt scroll-padding, specifically:

On 05/11/2018 11:13 AM, 'Majid Valipour' via blink-dev wrote:
> On Thu, May 10, 2018 at 10:50 PM Florian Rivoal <flo...@rivoal.net <mailto:flo...@rivoal.net>> wrote:
>
>     [...] Also, I don't know if you already do this or not, but please make sure that when you
>     support scroll-padding, you support its effects not just on scroll-snapping but on all kinds
>     scrolling, as specified. Otherwise, there is a forward compat risk: people sometimes use
>     JavaScript to correct the scroll position ... which would be bad.
>
> scroll-padding and scroll-margin will be supported on scrollIntoView and focus (relevant tests: 1
> <https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/external/wpt/css/cssom-view/scrollIntoView-scrollPadding.html?sq=package:chromium>,
> 2
> <https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/external/wpt/css/cssom-view/scrollIntoView-scrollMargin.html>).
> So the specific usecases you mention should be fine.

It needs to also affect page-up/page-down operations (both via keyboard and via scrollbar UI).
This is among of the most important aspects of scroll-padding, from a "replace scrolljacking
workarounds" perspective. (The point is to mask out part of the scrollport from scrolling
operations that bring content into view, so that UIs that used fixed-positioned panels don't
end up hiding content when scrolling by page--currently pages handle this by adjusting the
scroll position with JS.)

Do you have a sense of how often developers use "scrolljacking workarounds" to fix 
PageUp/PageDown operation to adjust scrollport to include fixed-position panels?
I am trying to better understand this usage pattern. So it will be great if you can share
a page or library that does this in practice.
 
It's harmful to ship support for scroll-padding without correctly supporting these cases,
since it makes @supports / .supports queries useless for detecting whether JS workarounds
are needed. The responsible options are to either fully support scroll-padding as specified,
or treat it as an unsupported property (disabled at parse time).

I just tested and Safari's version does not really do not change the PageDown/PageUp behavior.
So FWIW @supports is not really going to be reliable. Regardless, this may be something easy 
to fix and include. I will try putting up a patch that addresses this.

Majid

Majid Valipour

unread,
May 14, 2018, 1:49:12 PM5/14/18
to bra...@opera.com, Yoav Weiss, fantasai, Florian Rivoal, Chris Harrelson, suny...@chromium.org, blink-dev
On Mon, May 14, 2018 at 10:40 AM Daniel Bratell <bra...@opera.com> wrote:
Much in this thread has been about elements larger than the 
viewport/snapport and that the risk for that happening is not large. I 
wonder (and I'm sure this is in some spec somewhere), what happens if you 
zoom in so that elements become very large.

An image carousel was mentioned, and I can imagine someone zooming in to 
look closer at an image. Won't that become larger than the snapport in 
that case? What would happen with the scroll position?
/Daniel


There are multiple different ways to zoom. I assume you mean pinch-zoom which is
the most common zoom on mobile.

For pinch-zoom chrome scales its visual viewport. Chrome uses an inert visual
viewport model which keeps visual viewport transparent to the web for the most
part with few exceptions. 

Following this model, our initial plan was to make resizing the visual viewport
(e.g., as we do with pinch-zoom) not affect snapping at all. We found this does
not provide a good experience when zooming and scrolling the page so we are now
going to consider visual viewport when scroll snapping the frame. (crbug) 

In summary, when scrolling the document's scrolling element and that element has
snap positions, we consider the visual viewport scroll offset and size to
determine snapping behavior. For all other scrollers in the page, only the size
and scroll offset of the scroller itself will determine its snapping behavior
which is not affected by visual viewport.

That is our current plan but we are still experimenting here a bit so the above
behavior may change if we find a different model that works better.

Majid
 

Rick Byers

unread,
May 14, 2018, 4:03:17 PM5/14/18
to Majid Valipour, fantasai, Yoav Weiss, Florian Rivoal, Chris Harrelson, Sandra Sun, blink-dev
LGTM3 to ship with the "larger than viewports" issue solved (and appropriate WPT tests for that landed of course).

If handling that end up threatening to slip the feature more than one release, then let's follow-up (it's not clear to me if the accessibility concern is so severe as to justify slipping several releases).  But if you can get that (and the other remaining ship-blocking bugs) done in time for M69 then that certainly seems better than rushing to try to hit M68.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

fantasai

unread,
May 15, 2018, 6:51:07 AM5/15/18
to Majid Valipour, Yoav Weiss, Florian Rivoal, Chris Harrelson, suny...@chromium.org, blink-dev
Thanks~ Addressing that and the scroll-padding paging issue would resolve my concerns.

~fantasai

suny...@chromium.org

unread,
Jun 22, 2018, 11:59:38 AM6/22/18
to blink-dev, maj...@google.com, yo...@yoav.ws, flo...@rivoal.net, chri...@chromium.org, suny...@chromium.org
We'll enable CSSScrollSnap in M69. Here is our current status to the issues mentioned above:

- Areas larger than snapport: We have a patch ready for owner's review, and it'll land before M69 branch point.
- Including scroll-padding for paging: Landed