[css-scroll-snap-1] Path to interop among implementations

[majido]

Current Implementation State

Chrome is working on implementation of snap points and we are getting close to shipping it. So I spent sometime looking at the current state of various implementation. I have summarized my finding below

Given this, I believe what we will ship initially will match the current subset implemented by Safari with some additional features.

I like to use this issue to start a discussion around a practical plan to get interop on this specification.

Safari , Chrome (Behind a flag)

Safari is shipping a subset of current specification i.e., scrollsnap since at least Version 11.0.3 and have removed their previous prefixed implementation of old spec.

Chrome has an implementation in Canary channel which can be enabled via --enable-experimental-web-platform-features flag.

Here is some more detail around which features are implemented:

	Safari	Chrome	Test Page
Touch	Yes	Yes	webkit demo page [0]
Wheel	Yes	Yes
Scroll Bar	No	Partial[1]
Keyboard	No	No
Scroll{By,To}	Partial[2]	Yes	wpt test
Margin	old name [3]	Yes
Padding	Yes	Yes
Visibility	No	Yes	demo page
Large Element	No	No
Snap-Stop	No	No

[0] WebKit demo lists only the old syntax but the example use old and new so it works in Safari 11.
[1] Chrome scrollbar snapping only works for dragging
[2] Seem to be working only on viewport scrolling element but no inner scroller
[3] Safari is using scroll-snap-margin

Firefox & Edge

Firefox and Edge still ship the old spefication, i.e., snappoints.

Path to Interop

Firefox has an issue to implement the new CR specification but there has not been any implementation progress as far I can see since the issue was filed two years ago. The public info on Edge plans suggests that updating the implementation is on the backlog but no new update for past two years.

It will be great to find out more about intention of Firefox and Edge.

Tests

Chrome has been upstreaming tests as we have been implementing the feature. See:
https://wpt.fyi/css/css-scroll-snap/

They cover key aspects but I suspect we need more tests covering edge cases. Hopefully there will be more tests as other implementations update to the new specification

Communication to Authors on Usage of Old Properties

I wasn't able to find a lot of content on how the spec has evolved and how common patterns of usage can be migrated or potentially implemented in a way to work in both versions of the spec.

If we expect the old properties to continue being used for a while longer, I feel such communication may be valuable.

For example a horizontal carrousel can be implemented as follow:

.container {
    overflow-x: scroll;

    /* old spec */
    scroll-snap-type: mandatory;
    snap-destination: 50% 50%;

    /* new spec */
    scroll-snap-type: x mandatory;
}

.center-aligned-child {
   /* old spec, probably also use -ms, and -webkit */
   scroll-snap-coordinate: 50% 50%;
   
   /* new spec */
   scroll-snap-align: center;
}

.start-aligned-child {
   /* old spec, probably also use -ms, and -webkit */
   scroll-snap-coordinate: 0% 0%;
   
   /* new spec */
   scroll-snap-align: start none;
}
.end-aligned-child {
   /* old spec, probably also use -ms, and -webkit */
   scroll-snap-coordinate: 100% 100%;
   
   /* new spec */
   scroll-snap-align: end none;
}

In particular, I suggest we strongly discourage usage of scroll-snap-points-{x, y} from old syntax since there is no good way to have closely matching behavior without lots of hacks and additional elements.

[css-meeting-bot]

The Working Group just discussed css-scroll-snap.

The full IRC log of that discussion

<dael> Topic: css-scroll-snap
<dael> github: https://github.com//issues/2523
<dael> majidvp: Chrome we're impl scroll-snap. We're close to shipping. I tried to understand what other browsers impl. They're completely different.
<dael> majidvp: In 2016 WG resolved to fundamentally change the spec. Older spec mostly coordinate based and new is element based. New model I htink is fundimentally better because it lets UA make a better decision.
<dael> majidvp: At the time I think all impl agreed it's good and spec is in CR.
<dael> majidvp: Only Safari impl matches spec. Mozilla ships unprefixed old spec and I see a bug a few years ago for that. Same with Edge/IE they're an even older version os the spec.
<dael> majidvp: 2 vendors impl old, Safari is close to new, Chrome will ship close to Safari but prob cover more spec.
<dael> majidvp: Wanted to see if there's updates from other vendors.
<dael> fantasai: I'd like to mention it's important that whoever impl scroll padding and ships impl the behavior spec to apply to containers without snapping turned on. If we want that to ever work it needs to work when you turn on scroll padding so people can detect it exists.
<fantasai> s/scroll padding/scroll-padding/
<dael> astearns: Comment from Edge folks?
<dael> Rossen: Looking for current status.
<dael> florian: I think it says you plan to do it.
<dael> Rossen: We haven't started work. Under considerations.
<dael> dbaron: I think updating we looked at doing in the medium term. Possibly in next year, not next few months.
<tantek> For reference: our (Mozilla) bug to update to the scroll-snap CR: https://bugzilla.mozilla.org/show_bug.cgi?id=1231777
<dael> majidvp: I wouldn't be surprised that since there's an impl that switching to element based won't be hard to do. Safari I think managed to switch the modal. Seems reasonably straight forward.
<tantek> It's also in our 2018 priorities though we're not sure we'll get to it: https://wiki.mozilla.org/CSS#2018_Priorities
<dael> smfr: Impl wasn't too bad. Some compat problems.
<tantek> s/get to it/get to it in 2018
<dael> majidvp: Seems that for next year the old impl will exist. Next topic is if we should have explicit comments on how to migrate from the old snap points syntax to migrate to the new and if there's a subset of old that can be used.
<dael> majidvp: For example, old had destination and coordinates and they would align. Similar enough to the new spec that if you impl you can use the old and new models at the same time. We should have comments that this is safe to do, but don't use old.
<dael> tantek: I'd rather not encourage authors to use any old syntaxes to reduce compat shadow we create as a whole. I don't think we should rec older syntaxes.
<dael> florian: I've made demos that work in both old and new and you have to use both syntaxes but that's all you can do.
<dael> tantek: We don't want to support old going forward and if someone uses it because there's documentation on how to do it it increases the risk.
<dael> tantek: You increase the risk people create more stuff on the web with the old.
<dael> astearns: That they'll create stuff with old and new so it doesn't break when you move.
<dael> majidvp: But it would be hard to measure they used both. I think I agree encouraging using both may not be right. w
<dael> astearns: Anything more?
<dael> majidvp: One last thing, spec didn't have tests. AS we impl we added tests, but I wanted to make a suggestion to other impl that as they impl it would be nice to have more tests.
<dael> florian: I'm not impl but considering writing some tests. It's nice you've got basic and I'll ping you to get a review when I write for edge cases.

[frivoal]

@majido This was a good discussion to have, but I wonder if there's anything more that needs to be done here. Should we now close this issue?

[majido]

That is right. We do not need to do anything done here. This issue was meant to be a place to start and capture the discussion which it has. Closing.