- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Aug 2016 03:37:02 +0000
- To: public-css-archive@w3.org
frivoal has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-scroll-snap] scroll-snap-padding vs scroll padding == The section about [scroll types](https://drafts.csswg.org/css-scroll-snap/#scroll-types) distinguishes between 3 types of scrolling. The new prose looks better to me than the old one, but I am not satisfied that the [issue I raised a while back](https://lists.w3.org/Archives/Public/www-style/2016Apr/0094.html) is resolved, and I still see a distinction between explicit end positions and implicit end positions. In the following cases, the user indicates an explicit end position: - a panning gesture, released without momentum - manipulating the scrollbar “thumb” explicitly - programmatically scrolling via APIs such as scrollTo() In these following cases however, the user **does not** indicate an explicit end position, and instead, merely expresses the which that the thing in question is brought to any position within an acceptable range. It is the UA, not the user, that decides, whithin this acceptable range, which specific end position we should go after. - tabbing through the document’s focusable elements - navigating to an anchor within the page - moving the caret in an editable element Once the end position has been picked, I think I agree these two categories result in the same behavior. But the reason I believe it is useful to distinguish between them is that there is something to be said in the spec about what the acceptable range is. Specifically, I believe that this acceptable range should be the scroll snapport, not the scroll viewport. Now, to be fair, this picking of a position within the acceptable range isn't actually about snapping, and conceptually happens before the snapping logic kicks in. Which leads me to believe that the `scroll-snap-padding` property should be renamed into `scroll-padding`, and in addition to doing what it is currently defined to do with regards to snapping, it should also define the acceptable range of end position from which the UA is free to pick when converting a user's implicit scroll request into an explicit end position to be the "scroll snapport", even if there is no snapping involved in anyway, and even if `scroll-snap-type` is `none`. Whether it is because the author wants to give some breathing room around the content, or to avoid having the content that has been scrolled / snapped into view to be obscured by a fix-pos overlay or similar, the use cases that justify having a non zero scroll-snap-padding when snapping are just as valid when no spanning is involved and we're dealing with implicit scrolls. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/395 using your GitHub account
Received on Wednesday, 10 August 2016 03:37:13 UTC