Join GitHub today
[css-scroll-snap] scroll-snap-padding vs scroll-padding #395
The section about 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 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:
In these following cases however, the user does not indicate an explicit end position, and instead, merely expresses the wish that the thing in question is brought to any position within an acceptable range. It is the UA, not the user, that decides, within this acceptable range, which specific end position we should go after.
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
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
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 snapping is involved and we're dealing with implicit scrolls.
EDIT: fixed a few typos
(note: @fantasai raised a similar concern here: https://lists.w3.org/Archives/Public/www-style/2016Feb/0081.html)
Ok, correct me if I'm wrong, but the proposal here is to
I would propose also to have PageUp/PageDown respond to
Key considerations of this proposal:
I'm in favor of this proposal.
How would this be different from the already-spec'd behavior for proximity snap points? UAs already have the leeway to elect to snap to any given element in these scenarios if appropriate.
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
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.
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.
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.
To respond to your points...
To summarize again, the proposal consists of exactly two points:
I think it is fairly straightforward, solves a number of additional problems that exist with scrolling, and does not prevent us from providing even finer controls in the future should they be necessary.
You still seem very focused on the syntax. I can understand why you would associate this new functionality with snapping since both involve "where the scroll goes". However that's where the similarities end I think: snap positions are specifically specified as providing "particular alignments of content within a scroll container" whereas the new proposed functionality doesn't describe any alignment but only a reduced "in view" concept.
In fact, if the feature is primarily designed to provide an "in view" concept, I think it has many further implications unrelated to scrolling. Off the top of my head:
A feature that unambigously defines an "in view" region could do these things in addition to modifying ScrollIntoView behavior, but to call that feature
Your suggestion of features for an “in view” concept is very different from the one here. It also involves painting, i.e. a
However the “in view“ concept in this proposal is not about whether the element is actually visible, but whether it is
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:
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
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
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.
CSSWG Discussion: This topic will be added to the TPAC agenda.