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
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
Entry on the feature dashboard
--
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.
--
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/CABQcQ%2BHhjRrPmAhUrUy57DQZ-%2B1a63o0epguqSUCYUT9RSCsPw%40mail.gmail.com.
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB8RdXtu9C1b677BzRGU8LmyNw_i%3DUZyCAs3D%2BiejffJiwy8FQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/C273E1BB-A77E-49EC-B7A5-D4D9D7ADD782%40rivoal.net.
[...] 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.
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?
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.
> 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.
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.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/64ce6850-a0fb-43e5-bab1-bf390e07b5d9%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQcQ%2BG2HDG6Pe5ZyFmj19JFee4u6XOY0LvaBzefYFmXa%3DGFXg%40mail.gmail.com.
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?
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/CAFUtAY9WoMfy-2iEZanw4xZJO658FxC5Q%3DKRD5NoSNvF4vPEdQ%40mail.gmail.com.
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.
--
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/F9CC643F-CDCE-42E3-B21F-EF4551D49D88%40rivoal.net.
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).
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
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB8RdXv3CiB-EXVrCgQ5RPbhk9kp0Y4ZK0VgQbxEDi9Csf78%3Dw%40mail.gmail.com.