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

I have a difficult time understanding how arguments against 
scroll-padding do no apply equally well against scroll-snap-padding, 
or inversedly. The motivations for both are exactly the same: in cases
 where the UA is partly or totally controlling the end scroll 
position, the author wants to designate an area within the scrollport 
where it is desirable to place the things that are being scrolled to.

For example, @ChumpChief said:

> This brings me to the first solution option: UAs just get smarter 
about whether the target of the scroll is obscured by something at a 
given offset when selecting their destination.

Why is this not true for scroll-snap-padding use together with 
snappoints as well? In both cases, it seems to me that this might be 
doable in some cases, but is hard in the general case. If you feel 
this is an area where improvements can realistically be expected, I 
don't mind adding an `auto` value to scroll-(snap-)padding. But I 
don't see why anything that would work for the regular scrolling case 
wouldn't work just as well for the snapping case.

> A more general approach would be to define the geometry of obscuring
 elements, but by restricting the feature in this manner we guarantee 
that the range of scroll offsets that put an element "in view" is 
contiguous.

Again, same question? What about this is different between regular 
scrolling and snapping? As far as I can tell, scroll-snap-padding does
 exactly that: it defines a (simplified) geometry of obscuring 
elements 

---

Whether the UA is scrolling to a certain thing because of proximity 
snap points, or because of mandatory snap points, or because of 
navigating to an anchor, or because of focusing a button doesn't make 
a fundamental different. Regardless of the syntax, we're discussing a 
property that means "if you're going to scroll to something, put it 
within **there**, as long as that doesn't require overscroll".

Taking one single concrete example: let's say you have a long form 
document, with anchors spread throughout, and proximity snapping on 
the subsection titles. Say that it also has a semi-transparent reading
 progress indicator at a fixed position overlapping the top of the 
scroller, and a semi transparent (that becomes opaque when hovered) 
dock of social media buttons at a fixed position overlapping the 
bottom of the scroller. For the sake of the argument, let's say both 
these things are 20px high.

To avoid subsection titles being snapped at the edge of the scroller 
where they would be partly obscured by the semi transparent things, 
you add `scroll-snap-padding: 20px 0` (or `scroll-snap-padding: 20px`,
 in a vertical scroller the effect will be the same), and now when 
they snap, they snap in a comfortable place.

In the same document, when the user clicks a link that takes them to a
 anchor that's not placed on a subsection title, the thing they 
navigate to will be placed under the semi-transparent progress bar. 
That makes no sense to me: the author has already told us via 
scroll-snap-padding that this was not a good place to put things.

I'm certainly open to the idea that I may have overlooked something, 
but to help me understand what, could you provide a concrete example, 
in a similar spirit to the one I gave above, which shows a situation 
where the author sets scroll-snap-padding (as currently specified) in 
a way that makes sense, but where giving it the additional behavior 
fantasai and I are arguing for would do something that the user would 
consider detrimental?

You've mentioned the interaction between scroll-snap-padding and 
scroll-snap-margin. A simple way to fix this discrepancy would be to 
apply the same logic to scroll-snap-margin, make it into 
scroll-margin, and have that apply as well when the UA scrolls to for 
instance a button that just got focused and that has a scroll-margin.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/395#issuecomment-245522257 
using your GitHub account

Received on Thursday, 8 September 2016 07:58:33 UTC