W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2016

[csswg-drafts] [css-scroll-snap] scroll-snap-padding vs scroll padding

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Wed, 10 Aug 2016 03:37:02 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-170320870-1470800221-sysbot+gh@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

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