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

This proposal was clarified on the call today, but since more 
technical discussion was required we agreed to continue the 
conversation on the issue (here).

The proposal is that even for `scroll-snap-type: none`, and even for 
elements with unspecified `scroll-snap-margin`, the 
`scroll-snap-padding` (perhaps renamed) would have some effect on 
final scroll offsets for a class of scroll operations that bring a 
particular "thing" into view.  That "thing" may not necessarily be an 
element, e.g. in the case of the caret, so I'll refer to it as the 
"target" in this post.

As I mentioned on the call, I think this is an interesting problem to 
consider.  But I think it's best to discuss the problem being raised 
first before getting to implementation details.

# Problem
Certain user actions scroll the content with the intent of bringing 
something "into view".  The primary issue that was raised on the call 
involves content with a fixed element banner/toolbar on the top or 
bottom.  In this case, scrolling the content such that the target is 
contained within the viewport is necessary but not sufficient -- it 
may still be obscured by those fixed banners/toolbars.  This sucks.

# Approaches
To avoid this a UA would need to scroll the content such that the 
target is not just within the viewport, but also not intersecting with
 the obscuring content.  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.  I haven't thought about this in any detail but on the 
surface it seems like a solvable problem.  I would certainly consider 
this the most preferable since it wouldn't require work from the 
author.

But to continue the thought experiment for now let's assume that 
approach doesn't work -- maybe the UA can't divine enough information 
about the content without hints from the author.  OK, well, common 
design patterns today involve the banner/toolbar stretching the entire
 width of the screen, so a simplifying assumption is to assert the 
"obscuring content" can be adequately described with a simple offset 
from the top/bottom of the viewport.

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, which is nice.  So with those assumptions it does seem 
that you would need a property that defines the unobscured region 
which syntactically sounds like a padding.  And the UA would need to 
modify their scrolling logic to account for this padding in some sane 
way.  I think we all agree on that part.

# Using `scroll-snap-padding` specifically
I can understand how `scroll-snap-padding` was raised as a candidate 
for this purpose, but adding this additional responsibility to the 
feature overloads it to the point of damaging both features and 
introduces many more landmines for authors in the form of unintended 
side effects:

- The current semantic of CSS Scroll Snap is around specific alignment
 of a scroll snap area against the scroll snapport.  The candidate 
feature is not looking for a specific alignment but rather an 
"acceptable range".  This discrepancy is the main root cause of the 
further issues raised below.
- Snap positions are defined using both the `scroll-snap-padding` and 
`scroll-snap-margin`.  It is not obvious from CSS alone whether 
`scroll-snap-padding` is sufficient on its own to define an 
"acceptable range".  E.g. if the author has `scroll-snap-padding: 
50px; scroll-snap-margin: 50px`, then does the "acceptable range" 
start at 50px or 100px?
- In a more extreme case, an author might set a negative 
`scroll-snap-padding` and rely on a more-positive `scroll-snap-margin`
 to bring it back to the desired location.  Not saying this would be a
 recommended practice, but could result in some really nasty behavior 
if only the `scroll-snap-padding` was considered.
- It is not obvious from CSS alone if `scroll-snap-padding: 50px; 
scroll-snap-align: none start;` (which only results in snapping in the
 block axis) should also constrain the target of the scroll in the 
inline axis or if the author was just careless with shorthand since it
 didn't impact snapping.
- It is not obvious from CSS alone if the "acceptable range" for my 
snapping elements is the same as the "acceptable range" for any other 
target.  E.g. I may want to snap to each page in a document editor 
with a little breathing room, but not prematurely trigger scrolling if
 the user clicks to place the caret somewhere within the "breathing 
room" zone.
- It is not obvious from CSS alone if `scroll-snap-padding` should 
"encourage" aligning the target against the padding, and I think 
Florian and Elika are saying different things on this point.  If you 
think the padding describes "where in the viewport the focused content
 should go when scrolling to something on the page in general" as 
Elika says then it would imply that alignment should be encouraged.  
Alternatively if you think it should "define the acceptable range of 
end position from which the UA is free to pick" as Florian says then 
alignment should not be encouraged.
- Depending on your opinion for the previous bullet point, it may 
become more or less important to treat `scroll-snap-padding: 0` as a 
magic number that disengages this behavior, since it is the initial 
value.
- The definition of an "acceptable range" assumes that the padding is 
usually set to match the unobscured region.  This may be more likely 
(but not guaranteed) in the case of `scroll-snap-align: none start;` 
or `none end`, but less so for `scroll-snap-align: center`.  An author
 may not even care to set the `scroll-snap-padding` if they use both a
 top and bottom banner/toolbar since `scroll-snap-padding: 100px 0` is
 effectively the same as `scroll-snap-padding: 0` when using 
`scroll-snap-align: center`.  Or worse, if they have asymmetric 
toolbars (e.g. 200px top bar, 100px bottom bar) but want to keep the 
item centered in the viewport, they'll have to sacrifice one of those 
goals.  There would be no way to both accurately describe the obscured
 region AND keep the element centered in the viewport.
- It seems likely that authors may neglect to set the 
`scroll-snap-padding` on the non-snapping edge of the snapport.  If an
 author has both a top and bottom toolbar, `scroll-snap-align: none 
start` and `scroll-snap-padding-top: 100px` is sufficient to get 
proper top snapping.  Setting `scroll-snap-padding-bottom` would have 
no effect on snapping, so they may not realize it's required to ensure
 the bottom toolbar doesn't obscure the target.
- `scroll-snap-type: none` is intended to be the "big off switch" for 
the feature without requiring the author to additionally reset all of 
the other properties [1].  If this off switch is not honored in this 
case, then the author needs to additionally remember to reset the 
`scroll-snap-padding` to avoid inappropriate behavior from the 
half-off state.

[1] https://lists.w3.org/Archives/Public/www-style/2015Mar/0156.html

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

Received on Wednesday, 17 August 2016 18:58:40 UTC