W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2019

Re: [csswg-drafts] [css-scroll-snap-1] Compat between webkit and blink/gecko regarding "implicit" scroll boundary snap positions (#4037)

From: Justin Grant via GitHub <sysbot+gh@w3.org>
Date: Tue, 16 Jul 2019 22:17:20 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-512009155-1563315439-sysbot+gh@w3.org>
As long as implicit snap positions at scrollmin/scrollmax can be turned off somehow via CSS or JS, I don't have a strong opinion about the default behavior.

Sounds like we're not going to agree on the importance of supporting scroll snap with virtual scrolling implementations. Thanks for your thoughts here; you've helped me understand other facets of this problem.

> I have found that writing scroll/touch handlers on top of pointer events or things like hammer.js and the transform serves those gestures far better

Yep, that's what I'll have to do on my current project. Even if WebKit provides a no-implicit-edge-snapping option, it'll be too late for a Summer '19 release that I'm committed to. It'd still be good for other developers and my own future work to just be able to rely on CSS only for snapped scrolling.

> if the first piece of content has a margin on that start boundary you’re then asking to rework the other stylings

Yep, agreed. Still orders of magnitude easier than building JS-based scrolling from scratch, though. But regardless, I'm supportive of the option you're looking for, and OK if it's the default as long as there's a way to opt out.

> I think with responsive scroll containers and content “no elements” wouldn’t be the common reason as much as the element that defines the nearest scroll boundary alignment is attempting to align to the opposite edge of the scroll boundary, but is too large.

Makes sense, thanks for clarifying.  Is "element too big for desired scroll snap" also a problem for elements in the middle, or only at the edges of the content? If the former, how would the developer fix it?

> I find the behavior for the third scroller strange in both. 

Yep, "strange" was the point of the third example. It's just a plain-HTML/CSS (not virtual) list meant to highlight the problem behavior, not to represent realistic HTML that anyone would want to use. Only the top list is virtual.

GitHub Notification of comment by justingrant
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4037#issuecomment-512009155 using your GitHub account
Received on Tuesday, 16 July 2019 22:17:24 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:50 UTC