CSS Snap Points: Event Model Missing

[scottjehl]

It would be useful if CSS Snap Points had an event model for events like say, snapstart, snapstop, and snapchange. Currently, we can listen for scroll events and try to simulate these events, but it's hard to pinpoint when a native snap starts and ends, as opposed to a user-driven scroll.

[tabatkins]

Yeah, def.

[fantasai]

Note: In the interest of wrapping up the existing set of functionality (which is well-specced and pretty much done), we're deferring the event model until a later level of CSS Scroll Snap.

[pavelkornev]

Up. @fantasai Isn't it time?

[fantasai]

@pavelkornev It is. I unfortunately don't have the expertise to draft something up, but I'm happy to accept proposals. :) They'd go into Level 2, but we can certainly start a draft as soon as there's something to put in it.

[tunelinks]

I believe if a user scrolls or shrinks their viewport the snap should move the scrollbar to the center so it can be more responsive. Please see this for example and move your scrollbar to another position and then shrink the browser. https://codepen.io/anon/pen/jRjpQv

[jonjohnjohnson]

@tunelinks your concerns are already handled in the spec with this language...

If the content or layout of the document changes (e.g. content is added, moved, deleted, resized) such that the content of a snapport changes, the UA must re-evaluate the resulting scroll position, and re-snap if required. If the scroll container was snapped before the content change and that same snap position still exists (e.g. its associated element was not deleted), the scroll container must be re-snapped to that same snap position after the content change.
https://drafts.csswg.org/css-scroll-snap/#snap-strictness

Though implementors have yet to implement this logic. Chime in on filings like these to encourage implementation.

• https://bugs.chromium.org/p/chromium/issues/detail?id=866127
• https://www.chromestatus.com/feature/5865619656278016

Also, your concern isn't exactly related to the original issue above.

[DrummerHead]

Is this what I need to know to make a spec proposal? Or is there more documentation?

[frivoal]

@DrummerHead, yes, that (and the things linked from it) is a good starting point. I would also add that it is usually recommended to be very explicit about the uses cases you are trying to solve with your proposal. A problem that is obvious to you may not always be obvious to others, and unless we all understand what it is that we're trying to solve, it can be hard to agree on the best way to solve it.

[fantasai]

@DrummerHead The TAG drafted an "explainer explainer", which is maybe a good starting point. But basically, a proposal to solve this needs to A) define some syntax, B) explain at least at a high level the expected behavior, and C) explain some of the use cases it solves, with some examples. It doesn't have to be super formal, just so long as it communicates those three things. :)