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: jonjohnjohnson via GitHub <sysbot+gh@w3.org>
Date: Wed, 17 Jul 2019 00:56:15 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-512058519-1563324973-sysbot+gh@w3.org>
> Is "element too big for desired scroll snap" also a problem for elements in the middle, or only at the edges of the content?

Even if `mandatory` is set, I believe all implementations still allow for content be reached in the middle based upon language here -> https://drafts.csswg.org/css-scroll-snap-1/#choosing. But again, I’m concerned about hostility against reaching “home” as you say, especially when a box’s content edge might be pushed further inside the scrollers edge with margin, so the top of the text doesn’t meet/smash against the scroller edge.

> Yep, "strange" was the point of the third example. It's just a plain-HTML/CSS (not virtual) […] Only the top list is virtual.

The top list behaves quite normally for me in webkit, actually better than blink. In blink, I can only scroll a few past a few items at a time no matter how “hard” I attempt a scroll to move me far in either direction. In webkit, it’s affording me short scrolls to snap a few forwards or backwards as well as a “hard” scroll to reach the beginning or the end. Somehow webkit feels more intuitive for gestural (track/touch) scrolling, though I have not attempted wheel scrolling.

GitHub Notification of comment by jonjohnjohnson
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4037#issuecomment-512058519 using your GitHub account
Received on Wednesday, 17 July 2019 00:56:16 UTC

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