{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/csswg-drafts/issues/395","repository_url":"https://api.github.com/repos/w3c/csswg-drafts","labels_url":"https://api.github.com/repos/w3c/csswg-drafts/issues/395/labels{/name}","comments_url":"https://api.github.com/repos/w3c/csswg-drafts/issues/395/comments","events_url":"https://api.github.com/repos/w3c/csswg-drafts/issues/395/events","html_url":"https://github.com/w3c/csswg-drafts/issues/395","id":170320870,"number":395,"title":"[css-scroll-snap] scroll-snap-padding vs scroll-padding","user":{"login":"frivoal","id":113268,"avatar_url":"https://avatars.githubusercontent.com/u/113268?v=3","gravatar_id":"","url":"https://api.github.com/users/frivoal","html_url":"https://github.com/frivoal","followers_url":"https://api.github.com/users/frivoal/followers","following_url":"https://api.github.com/users/frivoal/following{/other_user}","gists_url":"https://api.github.com/users/frivoal/gists{/gist_id}","starred_url":"https://api.github.com/users/frivoal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/frivoal/subscriptions","organizations_url":"https://api.github.com/users/frivoal/orgs","repos_url":"https://api.github.com/users/frivoal/repos","events_url":"https://api.github.com/users/frivoal/events{/privacy}","received_events_url":"https://api.github.com/users/frivoal/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/w3c/csswg-drafts/labels/css-scroll-snap-1","name":"css-scroll-snap-1","color":"c5def5"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2016-08-10T03:37:01Z","updated_at":"2016-08-17T18:58:32Z","closed_at":null,"body":"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.\r\n\r\nIn the following cases, the user indicates an explicit end position:\r\n- a panning gesture, released without momentum\r\n- manipulating the scrollbar “thumb” explicitly\r\n- programmatically scrolling via APIs such as scrollTo()\r\n\r\nIn 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.\r\n- tabbing through the document’s focusable elements\r\n- navigating to an anchor within the page\r\n- moving the caret in an editable element\r\n\r\nOnce 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\r\nthere is something to be said in the spec about what the acceptable range is.\r\n\r\nSpecifically, 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.\r\n\r\nWhich leads me to believe that the `scroll-snap-padding` property should be renamed into \t`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 any way, and even if `scroll-snap-type` is `none`.\r\n\r\nWhether 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.\r\n\r\n*EDIT: fixed a few typos*"},"comment":{"url":"https://api.github.com/repos/w3c/csswg-drafts/issues/comments/240512298","html_url":"https://github.com/w3c/csswg-drafts/issues/395#issuecomment-240512298","issue_url":"https://api.github.com/repos/w3c/csswg-drafts/issues/395","id":240512298,"user":{"login":"ChumpChief","id":4276348,"avatar_url":"https://avatars.githubusercontent.com/u/4276348?v=3","gravatar_id":"","url":"https://api.github.com/users/ChumpChief","html_url":"https://github.com/ChumpChief","followers_url":"https://api.github.com/users/ChumpChief/followers","following_url":"https://api.github.com/users/ChumpChief/following{/other_user}","gists_url":"https://api.github.com/users/ChumpChief/gists{/gist_id}","starred_url":"https://api.github.com/users/ChumpChief/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ChumpChief/subscriptions","organizations_url":"https://api.github.com/users/ChumpChief/orgs","repos_url":"https://api.github.com/users/ChumpChief/repos","events_url":"https://api.github.com/users/ChumpChief/events{/privacy}","received_events_url":"https://api.github.com/users/ChumpChief/received_events","type":"User","site_admin":false},"created_at":"2016-08-17T18:58:32Z","updated_at":"2016-08-17T18:58:32Z","body":"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).\r\n\r\nThe 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.\r\n\r\nAs 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.\r\n\r\n# Problem\r\nCertain 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.\r\n\r\n# Approaches\r\nTo 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.\r\n\r\nBut 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.\r\n\r\nA 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.\r\n\r\n# Using `scroll-snap-padding` specifically\r\nI 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:\r\n\r\n- 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.\r\n- 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?\r\n- 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.\r\n- 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.\r\n- 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.\r\n- 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.\r\n- 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.\r\n- 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.\r\n- 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.\r\n- `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.\r\n\r\n[1] https://lists.w3.org/Archives/Public/www-style/2015Mar/0156.html"}}
{"actor":{"display_login":"ChumpChief"}}