Review document: http://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
Editor's draft: http://dev.w3.org/csswg/css-snappoints-1/
The following color coding convention is used for comments:
Open issues are marked like this
An issue can be closed as Accepted, OutOfScope,
Invalid, Rejected, or Retracted.
Verified indicates commentor's acceptance of the response.
Issue 1. #
Summary: Snapping should be element-based
https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html (roc)
Snap offsets should be derived automatically from the layout
if the descendants of the scrolling container, so that changes to
that layout don't require manual updating of some property set on
the container.
https://lists.w3.org/Archives/Public/www-style/2013Oct/0570.html (tab)
Need to snap to elements.
https://lists.w3.org/Archives/Public/www-style/2014Feb/0816.html (roc)
I feel that the focus on length-based properties in the draft is a mistake
and starting with a focus on element boxes makes more sense. Hard-coding
lengths makes for fragile and non-responsive designs.
https://lists.w3.org/Archives/Public/www-style/2015May/0282.html (NYC 2015)
Authors want snapping to boxes, not having to do JS math against layout
Solution: scroll-snap-coordinate/destination or scroll-snap-area/align
Closed: Accepted
Issue 2. #
Summary: Interaction with transforms
https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html (roc)
Define interaction with transforms
Solution: rakow specifies that coordinates of snap point get transformed with element
Solution: TF specifies that scroll-snap-area originates as bounding box of transformed border/margin-box
Closed: Accepted
Issue 3. #
Summary: Handle overly-large elements properly
https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html (roc)
Allow UAs to not snap when box is larger than scroll-port
https://lists.w3.org/Archives/Public/www-style/2013Oct/0574.html (roc)
Summary: Need to be able to scroll an overly-large element without it forcing a snap, even if it's "mandatory".
https://lists.w3.org/Archives/Public/www-style/2014Jan/0592.html (rakow)
Use case: Freely scrolling areas within "boundaries" that resist scrolling
https://lists.w3.org/Archives/Public/www-style/2014Mar/0008.html (roc)
Mandatory snapping should be disabled when box fills viewport
https://lists.w3.org/Archives/Public/www-style/2014Mar/0014.html (rakow)
Changing behavior based on size is confusing
https://lists.w3.org/Archives/Public/www-style/2014Mar/0025.html
Authors are dumb when it comes to varying size viewports, we have to help users
https://lists.w3.org/Archives/Public/www-style/2015Jan/0009.html (TPAC 2014)
Need to consider varying screen sizes, esp wrt mandatory snap points
https://lists.w3.org/Archives/Public/www-style/2015May/0282.html (NYC 2015)
Current proposal doesn't handle varying viewport sizes
Solution: Making all views in which element fills viewport a valid snap position
https://drafts.csswg.org/css-scroll-snap/#scroll-snap-align
Closed: Accepted by TF
Issue 4. # Summary: Need a way to snap to the center of an element. https://lists.w3.org/Archives/Public/www-style/2013Dec/0303.html (rakow) Solution: scroll-snap-destination: center + scroll-snap-coordinate: center / scroll-snap-align: center Closed: Accepted
Issue 5. #
Summary: Need a way to snap while "peeking" the next/prev thing a little bit.
https://lists.w3.org/Archives/Public/www-style/2013Dec/0303.html (rakow)
https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html (roc)
Use offsets plus box-name
Solution: scroll-snap-destination: 10px [only works in one direction] / scroll-snap-area: 10px
Closed: Accepted
Issue 6. # Summary: Define box-based scroll-snap with per-element padding/offsets https://lists.w3.org/Archives/Public/www-style/2013Aug/0226.html Solution: scroll-snap-area Closed: Accepted by TF Resolved: https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html
Issue 7. # Summary: Make sure this works with box-sizing, and uses consistent terminology. https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html (Seattle F2F) Solution: scroll-snap-area Closed: Accepted by TF
Issue 8. # Summary: scroll-snap-coordinate needs to allow specifying which box to use (margin vs border) https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html (roc) Solution: scroll-snap-area Closed: Accepted by TF [later dropped]
Issue 9. #
Summary: Add scroll snappoint repetition length
https://lists.w3.org/Archives/Public/www-style/2013Aug/0248.html (tab)
I'd add an additional property for setting explicit snap points
in addition to the implicit points coming from the children,
probably with a repetition syntax so you can set up a snap point every 100px or whatever.
https://lists.w3.org/Archives/Public/www-style/2013Aug/0253.html (roc)
I can't think of any [use cases] that wouldn't work better
using scroll-snap-edge on descendant elements.
Closed: Accepted
Solution: scroll-snap-points-x/y: repeat(<length>)
Issue 10. #
Summary: Remove scroll-snap-points-x/y: repeat() in favor of element-snapping
https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html (roc)
https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html (rakow)
snap-interval is needed for paging
Use case: Handle redfin filmstrip (repeat 9 photos, 10 photos visible)
https://lists.w3.org/Archives/Public/www-style/2014Mar/0025.html (roc)
[don't think this is user-friendly; your use case is invalid]
AFAICT the strip is not actually scrollable using any UA gestures, but only
using those buttons, so scroll snapping isn't relevant here.
If we consider a slightly different example where the strip is scrollable
via UA gestures as well as the buttons, I don't think you'd actually want
to snap to container-sized boundaries; that would just annoy users who try
to scroll a few more images into view and find they can't. Instead you'd
want to snap to the margin-box of each image. Those buttons are just
page-left/page-right controls and could be implemented just the same as
they are today, although we might want to extend CSSOM ScrollOptions with a
"snap" parameter so that the button event handler can opt into snapping
when calling scrollBy so it snaps to an image margin-box edge.
https://lists.w3.org/Archives/Public/www-style/2014Mar/0062.html (roc)
Use container.scrollBy(container.clientWidth, 0, {behavior:"smooth"})
https://lists.w3.org/Archives/Public/www-style/2015May/0282.html
Repeat seems unnecessary
Solution: Drop scroll-snap-x/y: repeat()
Closed: Accepted
Resolved: TPAC 2015
Issue 11. #
Summary: Multiple snap points per element
https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html (Seattle F2F)
Rossen: photos with faces
https://lists.w3.org/Archives/Public/www-style/2014Jan/0592.html (rakow)
Elements with multiple "points of interest" that can all be snapped to?
https://lists.w3.org/Archives/Public/www-style/2014Jan/0594.html (roc)
Use invisible elements representing the points of interest
Or image map <area> tags? Can we define how those snap? -- fantasai
Solution: Add elements to represent points of interest.
Closed: Accepted
Resolved: TPAC 2015
Issue 12. #
Summary: Allow snapping between multicol columns
https://lists.w3.org/Archives/Public/www-style/2013Aug/0257.html (fremy)
Authors might want to snap per-column
https://lists.w3.org/Archives/Public/www-style/2013Aug/0260.html (roc)
Create a ::column pseudo-element, snap to that
Solution: Use ::column pseudo-element, deferred to css-pseudo
Closed: OutOfScope
Resolved: TPAC 2015
Issue 13. # Summary: Snapping to grid lines? https://lists.w3.org/Archives/Public/www-style/2013Dec/0064.html (fremy) Solution: Snap to elements (don't see strong use case for when there aren't any) Closed: Rejected Resolved: TPAC 2015
Issue 14. # Summary: Use case for baseline aligned snap position https://lists.w3.org/Archives/Public/www-style/2014Mar/0014.html Closed: Deferred to future, but consider how it would work with -align
Issue 15. #
Summary: Don't see use case for scroll-snap-points-x/y given elements
https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html (roc)
I'm not sure that scroll-snap-points-x/y is really needed if we have
good support for scrolling to element edges. Is there a use-case where it's
useful to be able to specify snap-points that are not at the edge of some
element's box (or some fixed offset thereof)?
https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html (roc)
No use-case for scroll-snap-points-x/y. Just drop it.
https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html (roc)
I still think a case has not been made for scroll-snap-points-x/y to
support any value other than "elements", so we should get rid of it.
https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html (rakow)
Response: Removed scroll-snap-points-x/y offset list
Solution: Removed offset list
Closed: Accepted
Issue 16. # Summary: Should apply to more than just block-level boxes https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html (dbaron) Solution: Applies to all elements Closed: Accepted Resolved: TPAC 2015
Issue 20. #
Summary: Define that scroll gestures don't snap "backwards"
https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html (roc)
Guideline that scroll gestures with definite direction
do not scroll backwards to snap point
Solution: Added guideline to https://drafts.csswg.org/css-scroll-snap/#choosing
Closed: Accepted by TJ
Issue 21. #
Summary: Which user gestures are snapped?
https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html (roc)
Define that all user scroll gestures are affected by snapping
Solution: Clarified that all scroll gestures are snapped
Closed: Accepted
Verified: by unarchived email from roc
Issue 22. #
Summary: Do layout changes resnap?
https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html (roc)
Define that layout changes do not trigger resnapping
https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html
What should we do when when we're snapped, then the element moves?
For proximity, maybe okay to do nothing, but mandatory should re-snap.
https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html (rakow)
Spec update: Mandatory snap points must resnap when layout shifts
https://lists.w3.org/Archives/Public/www-style/2014Nov/0086.html (roc)
Concern wrt implementability of resnapping to layout changes
https://lists.w3.org/Archives/Public/www-style/2015Jul/0452.html (rakow)
Response: No, really, we need to resnap always otherwise authors
have to do it themselves manually.
Solution: Require resnapping https://drafts.csswg.org/css-scroll-snap/#snap-type
Closed: Accepted
Resolved: TPAC 2015
Issue 23. #
Summary: Resnap reaction to deleted snappoint?
https://lists.w3.org/Archives/Public/www-style/2015Jul/0458.html (roc)
What happens if that snap point ceases to exist?
https://lists.w3.org/Archives/Public/www-style/2015Jul/0479.html (rakow)
UA-defined, usually nearest or next element is good
https://lists.w3.org/Archives/Public/www-style/2015Aug/0000.html (roc, tab)
Need to specify which exactly, for interop
Closed: Accepted
Resolved: TPAC 2015
Issue 24. #
Summary: When do layout changes trigger resnapping?
https://lists.w3.org/Archives/Public/www-style/2015Jul/0458.html (roc)
When does this auto-snapping occur? On every layout?
Including layouts that occur during script execution?
https://lists.w3.org/Archives/Public/www-style/2015Jul/0479.html (rakow)
After OM/layout/display completes, provided no active scroll event
Closed: Accepted by TF
Resolved: TPAC 2015
Issue 25. #
Summary: Is DOM script-scrolling snapped?
https://lists.w3.org/Archives/Public/www-style/2013Aug/0224.html (roc)
Define whether script-driven scrolling is affected by snapping
https://lists.w3.org/Archives/Public/www-style/2014Nov/0086.html (roc)
Clarify whether JS scrollTop setting causes resnapping
https://lists.w3.org/Archives/Public/www-style/2015Jun/0230.html (bfulgham)
Spec doesn't say whether scrollTo/scrollLeft/scrollTop/scrollIntoView snap
https://lists.w3.org/Archives/Public/www-style/2015Jun/0231.html (roc)
No snapping for DOM Apis, but add 'snap' value to ScrollOptions
https://lists.w3.org/Archives/Public/www-style/2015Jun/0376.html (rakow)
Always snap to snappoints
https://lists.w3.org/Archives/Public/www-style/2015Jul/0035.html (majid)
Scroll APIs need to be able to evade snap restrictions
https://lists.w3.org/Archives/Public/www-style/2015Jul/0046.html (roc)
Having some JS operations snap and others not is weird
(Changing layout and script-scrolling should act the same.)
https://lists.w3.org/Archives/Public/www-style/2015Jul/0452.html (rakow)
Response: No, really, we need to resnap always otherwise authors
have to do it themselves manually.
Solution: Scroll positions are always snapped
Closed: Accepted
Resolved: TPAC 2015
Issue 26. # Summary: Add 'snap' parameter to CSSOM ScrollOptions (make not-snapping default) https://lists.w3.org/Archives/Public/www-style/2014Mar/0025.html https://lists.w3.org/Archives/Public/www-style/2015Jun/0231.html https://lists.w3.org/Archives/Public/www-style/2015Jul/0085.html Closed: Rejected, due to resolution of previous issue
Issue 27. #
Summary: Add some DOM APIs
https://lists.w3.org/Archives/Public/www-style/2013Dec/0375.html
[no clue what stuff, Tab you'll have to elaborate]
https://lists.w3.org/Archives/Public/www-style/2013Dec/0384.html (roc)
You can read and write the scroll position using scrollLleft/scrollTop and
the scroll event. In principle this is enough information to do whatever
you need. Some convenience APIs might be useful, e.g. to compute the
possible snapping destinations when scrolling in a particular direction.
Solution: scrollTop and scrollLeft
Closed: Rejected
Issue 28. #
Summary: Might be nice to have API to get snap destinations
https://lists.w3.org/Archives/Public/www-style/2013Dec/0384.html (roc)
Some convenience APIs might be useful,
e.g. to compute the possible snapping destinations
when scrolling in a particular direction.
Closed: Deferred
Resolved: TPAC 2015
Issue 40. #
Summary: Use flow-relative logical syntax
https://lists.w3.org/Archives/Public/www-style/2013Aug/0248.html (tab)
Should use logical directions for property/value naming
https://lists.w3.org/Archives/Public/www-style/2013Aug/0253.html (roc)
Layout isn't always logical
https://lists.w3.org/Archives/Public/www-style/2013Aug/0258.html (howcome)
Axis isn't usually defined by writing mode, but direction within axis is
Closed: Accepted by TF
Issue 42. #
Summary: Shorten "scroll-snap-type" to "scroll-snap"?
https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html (roc)
scroll-snap-type is too verbose. Shorten to scroll-snap?
https://lists.w3.org/Archives/Public/www-style/2015Nov/0328.html (fantasai)
Various shorthanding options
Open: Need more feedback on the proposals.
Issue 43. #
Summary: "snappoints" is a misnomer, since you're usually snapping to edge
https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html (roc)
Change name to css-scrollsnap, as we're not snapping points.
Solution: css-scroll-snap shortname
Closed: Accepted by TF
Issue 44. #
Summary: Should start/end of scroll container automatically be snap-points?
https://lists.w3.org/Archives/Public/www-style/2013Oct/0571.html (tab)
https://lists.w3.org/Archives/Public/www-style/2013Oct/0574.html (roc)
Maybe need implicit snap points at 0/end, but also there are use-cases for not doing it.
(Using snap-points for pull-to-refresh, for example, to hide the "pulled" part initially.)
https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html
Proposal for adding edges of an element's margin or border box
to the list of available snap points, in https://wiki.mozilla.org/index.php?title=Gecko:CSSScrollSnapping
https://lists.w3.org/Archives/Public/www-style/2014Aug/0397.html (ted)
What to do when the end of the box isn't a snap point, and type is mandatory?
Bounce, or assume there's one there anyway?
https://lists.w3.org/Archives/Public/www-style/2014Aug/0427.html (fremy)
Omitting the end can be useful to do pull-to-refresh behaviors at end.
https://lists.w3.org/Archives/Public/www-style/2015Jan/0009.html (TPAC 2014)
https://lists.w3.org/Archives/Public/www-style/2015Jul/0035.html (majid)
Way to make start/end of scrollable area snappable
Response: (rakow) Can't see a use case -- interval syntax includes it
implicitly, and for elements, there's no element there anyway
https://lists.w3.org/Archives/Public/www-style/2015Jul/0453.html
Note: WebKit implicitly adds these snappoints.
Solution: No automatic snap points at scrollable area edges, snap to elements as necessary
Closed: Rejected
Resolved: TPAC 2015
Issue 45. #
Summary: Independent scroll-snap-type per axis
https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html (Seattle F2F)
different snap types in x and y dimensions
https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html (roc)
Independent control of scroll-snap-type for vertical and horizontal axes
is essential. Imagine, for example, you're scrolling through a vertical
list of images of different sizes and some of them overflow horizontally.
We want to snap to image edges when scrolling vertically but do no snapping
when scrolling horizontally. With the current draft we can't do that.
https://lists.w3.org/Archives/Public/www-style/2014Jan/0592.html (rakow)
This interferes with 2D snapping
https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html (roc)
Independent control over vert and horiz snapping is needed.
(Scrolling through a vertical snapped list of items, but some might overflow.)
https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html
Note: FF implements axis-separate snap-type
https://lists.w3.org/Archives/Public/www-style/2015Oct/0213.html
Requirements are threefold:
1. single-axis snapping
2. both-axis snapping
3. 2D snapping
Solution: allow scroll-snap-align to specify one or both axis coordinates
Solution: add [ x | y | block | inline | both | point ] keywords
Closed: Accepted by TF
Resolved: https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html
Issue 46. #
Summary: Scroll-snap-coordinate needs x/y longhands
https://lists.w3.org/Archives/Public/www-style/2015May/0248.html (majid)
https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html (majid)
Note: FF implements axis-separate snap-type
Solution: scroll-snap-align / scroll-snap-area longhands
http://drafts.csswg.org/css-scroll-snap/#longhands
Closed: Accepted by TF
Issue 47. #
Summary: "scroll-snap-axis-x/y" / "scroll-snap-destination" poorly named
https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html (roc)
"scroll-snap-axis-x/y" seems like a poor name for something that
computes to a length value.
https://lists.w3.org/Archives/Public/www-style/2014Mar/0000.html (rakow)
Renamed to "scroll-snap-destination"
https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html (roc)
I still think that scroll-snap-coordinate and scroll-snap-destination are
terrible names.
https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html (roc)
Rename scroll-snap-coordinate to scroll-snap-target.
https://lists.w3.org/Archives/Public/www-style/2014Oct/0480.html (rakow)
"target"+"destination" confusing, maybe rename both?
Solution: scroll-snap-align / scroll-snap-padding
Closed: Accepted by TF
Resolved: https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html
Issue 48. #
Summary: "scroll-snap-coordinate-x/y" poorly named
https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html (roc)
https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html (roc)
I still think that scroll-snap-coordinate and scroll-snap-destination are
terrible names.
https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html
Solution: scroll-snap-align / scroll-snap-area
Closed: Accepted by TF
Resolved: https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html
Issue 49. #
Summary: Initial value of "scroll-snap-coordinate-x/y" bad
https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html (roc)
"scroll-snap-coordinate-x/y" has an initial value of 0px which means
that by default every element's box creates a snapping position. This makes
the "elements" feature unusable!
https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html (roc)
Initial value of scroll-snap-coordinate is bad
https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html (rakow)
Will fix
https://lists.w3.org/Archives/Public/www-style/2014Mar/0000.html (rakow)
Added 'none' as initial value
Closed: Accepted
Issue 50. # Summary: Bunch of stuff probably not needed? (not sure what stuff), need archaology https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html (roc) https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html (rakow)
Issue 51. #
Summary: Use commas in functional notation
https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html (roc)
Why aren't we using commas to separate function parameters?
https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html (rakow)
Going with CSS conventions
https://lists.w3.org/Archives/Public/www-style/2014Mar/0032.html (fantasai)
http://wiki.csswg.org/ideas/functional-notation#general-principles
Closed: Invalid
Issue 52. # Summary: scroll-snap-points syntax needs work https://lists.w3.org/Archives/Public/www-style/2014Mar/0046.html Response: Okay https://lists.w3.org/Archives/Public/www-style/2014Mar/0074.html https://lists.w3.org/Archives/Public/www-style/2014Mar/0075.html https://lists.w3.org/Archives/Public/www-style/2014Mar/0106.html Closed: Accepted
Issue 53. # Summary: Some syntactic concerns (hyphenization, commas) https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html (Seattle F2F) Closed: Accepted
Issue 54. # Summary: Have the children determine the scroll snapping behavior (proximity, mandatory), rather than container. https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html (Seattle F2F) Closed: Retracted Resolved: TPAC 2015
Issue 60. #
Summary: Add scroll jumping / "discrete snapping" feature
https://lists.w3.org/Archives/Public/www-style/2013Aug/0248.html (tab)
scroll-snap needs an additional value that abruptly jumps between the
snap points, rather than allowing smooth scrolling and then adjusting
to a snap point (this is used by things like spreadsheets).
https://lists.w3.org/Archives/Public/www-style/2013Aug/0249.html (roc)
Does this make sense for touch panning? I kinda doubt it does.
Maybe instead whether we abruptly jump between snap points
should be up to the UA and depend on the scroll mechanism?
https://lists.w3.org/Archives/Public/www-style/2013Oct/0570.html (tab)
Snap "discretely", rather than smoothly scrolling, like spreadsheets do.
https://lists.w3.org/Archives/Public/www-style/2014Mar/0014.html (rakow)
Consider a spreadsheet application, which generally snaps rows/columns
consistently to the top/left edge. [Or text editor.]
https://lists.w3.org/Archives/Public/www-style/2014Mar/0025.html (roc)
Spreadsheet scrolling behavior is evil.
Text editor case is imaginary afaict.
Solution: Add value to scroll-snap-type? Defer? Reject?
Closed: Deferred
Resolved: TPAC 2015
Issue 62. #
Summary: Mandatory snapping only when snap point is visible.
https://lists.w3.org/Archives/Public/www-style/2015Apr/0103.html
There should be a way to specify to only snap when there’s a snappoint
in the visible area of the scroll container. I’m trying to describe
something which feels in-between the current [mandatory] & [proximity]
values for [scroll-snap-type]. It could be named [visible]. In this
case [proximity] would be too loose, but [mandatory] too strict. You
don’t want to change the behavior of the current values, as they make
a lot of sense in other situations. So adding a new one is my suggestion.
Closed: Accepted
Note: Waiting for clarification from OP
Issue 63. #
Summary: Determine snap edge by scroll direction
https://lists.w3.org/Archives/Public/www-style/2013Dec/0284.html (roc)
Propose that when doing element-snapping,
automatically decide which edge to snap based on the direction you're scrolling.
E.g., snap bottom edge when scrolling down.
https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html (roc)
Per-gesture snapping points (top vs bottom depending on direction)
https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html (rakow)
This is weird and bad.
https://lists.w3.org/Archives/Public/www-style/2014Feb/0829.html (roc)
Disagree, not having this is bad. But only sensible for items fully in the scrollport
https://lists.w3.org/Archives/Public/www-style/2014Mar/0014.html (rakow)
You're wrong, there are more use cases than that.
https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html (roc)
Okay, I'm wrong. We can agree on this now.
Closed: Retracted
Issue 64. # Summary: Specify whether inertia can skip snap positions https://lists.w3.org/Archives/Public/www-style/2015Jan/0009.html (TPAC 2014) Solution: Make skipping the default, add scroll-snap-stop property for control. Closed: Accepted
Issue 65. #
Summary: "snap points" is a misleading term
https://lists.w3.org/Archives/Public/www-style/2013Oct/0574.html (roc)
I think the terminology "snap points" can be misleading. You don't snap to
Cartesian points, you snap to horizontal or vertical lines/edges. I suggest
renaming everything to not refer to points. "Positions" might be better.
Solution: Using "snap positions"
Closed: Accepted by TF
Issue 66. #
Summary: Make sure zooming doesn't interfere with snapping, or make it act in a weird/unpredictable manner.
https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html (Seattle F2F)
https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html (rakow)
Specified that visual viewport snaps, not layout viewport
Closed: Accepted
Issue 67. #
Summary: 2D snapping, such as cities on a map
https://lists.w3.org/Archives/Public/www-style/2014Jan/0592.html (rakow)
Diagonally positioned snappable elements in a 2d scroller, for example snapping to center on cities on a map
https://lists.w3.org/Archives/Public/www-style/2015Jun/0170.html
1D vs 2D snapping
Closed: Accepted, marked at-risk
Issue 68. #
Summary: Better definition of snapping behavior
https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html (roc)
Need more precise, consolidated definition of snapping behavior
Solution: "Scroll Snapping Model" and "Scroll Snapping Mechanics" sections
Closed: Accepted by TF
Verified: by OP via private email
Issue 69. #
Summary: Define what happens when there's no snap points
https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html (roc)
Mandatory snapping + no snap points = problem.
Suggest snapping to 0.
https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html (roc)
Solution: No snapping occurs
https://hg.csswg.org/drafts/diff/ee1b97add9cb/css-scroll-snap/Overview.bs
Closed: Accepted
Resolved: TPAC 2015
Issue 70. #
Summary: Define what happens when snap points cannot be satisfied without overscrolling
https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html (roc)
https://lists.w3.org/Archives/Public/www-style/2014Nov/0086.html (roc)
I think it's important to soon resolve the issue about what to do for
mandatory snapping when there's no reachable snappoint. I propose that if
there are no reachable snappoints at all, no snapping occurs. Otherwise we
scroll as far as we can to minimize the distance between the scroll
position and the nearest snappoint.
Solution: Snap to furthest valid scroll position
https://hg.csswg.org/drafts/diff/c283d8b6be5c/css-scroll-snap/Overview.bs
https://hg.csswg.org/drafts/diff/a55dada6cbcb/css-scroll-snap/Overview.bs
Closed: Accepted by TF
Issue 71. #
Summary: Define what happens with snap points outside of scrollable area
https://lists.w3.org/Archives/Public/www-style/2015Aug/0000.html
How should we react to a snappoint outside the scrollable area?
MS seems to consider it "invalid",
Safari keeps it choosable and scrolls as close as possible if it's chosen.
(Consider behavior when an element moves and its corresponding snappoint shifts slightly outside the scrollable area.)
Solution: Specified that scroll-snap-points-x/y don't generate more than one repetition outside scrollable area;
Handle out-of-range snap positions as above (snap to furthest possible point).
Closed: Accepted by TF
Issue 72. # Summary: Define that snap point defined by element is triggered when targeting fragment of element https://lists.w3.org/Archives/Public/www-style/2015Oct/0164.html Closed: Accepted by TF Resolved: =WG= Discuss.
Issue 80. #
Summary: Remove "scroll-snap-position-x/y:elements"
https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html (roc)
Just always snap to elements (union with -position lengths)
https://lists.w3.org/Archives/Public/www-style/2014Oct/0029.html (roc)
I still think a case has not been made for scroll-snap-points-x/y to
support any value other than "elements", so we should get rid of it.
https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html (Seattle F2F)
Remove the "elements" value from scroll-snap-points-x/y, and just merge the lists together.
https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html (rakow)
Removed
https://lists.w3.org/Archives/Public/www-style/2015Mar/0153.html
Removing 'elements' keyword makes it tricky to turn snapping off
Response: (rakow) Use scroll-snap-type as toggle
https://lists.w3.org/Archives/Public/www-style/2015Mar/0154.html
Closed: Accepted
Issue 81. #
Summary: Interaction of scroll-snap-points-x/y and element snappoints
https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html (roc)
Union element-based positions and snap-points-x/y positions
https://lists.w3.org/Archives/Public/www-style/2015Jun/0150.html (smfr)
Define interaction of scroll-snap-points-x/y and scroll-snap-coordinate
Closed: Accepted
Issue 82. #
Summary: Trapping snap points
https://lists.w3.org/Archives/Public/www-style/2015May/0282.html (NYC 2015)
Elements value is needed to trap scroll-snap contributions,
for cases where author decides to remove scrollability.
https://lists.w3.org/Archives/Public/www-style/2015Jun/0147.html (smfr)
Less sure about this now..
Also, nested scrollers issue -- need scrollers to trap snappoints
https://lists.w3.org/Archives/Public/www-style/2015Jun/0159.html (majid)
Separate capture from snapping
https://lists.w3.org/Archives/Public/www-style/2015Jun/0376.html (rakow)
Need some way to specify capture, maybe "elements"?
https://lists.w3.org/Archives/Public/www-style/2015Jul/0035.html (majid)
That doesn't prevent pass-through on scrollers. Need to be associated
to nearest scrollable ancestor, but only snap if 'elements' is specified.
https://lists.w3.org/Archives/Public/www-style/2015Jul/0457.html (rakow)
* Scrollability is defined by 'auto' or 'scroll' computed value
* Scrollability in an axis captures snappoints in that axis
* Do we really need snapping to pass through per axis?
* Priorities of nested snapping vs 2D snapping?
https://lists.w3.org/Archives/Public/www-style/2015Oct/0211.html (fantasai + Tab)
Two issues:
1. Specifying that 'overflow'-based trapping either
A. In both axes
B. In scrollable axes
2. Allowing elements that aren't scroll containers to trap snap points;
suggest using 'scroll-snap-type' applied to all elements.
Solution: Defined that 'overflow: scroll/auto' in an axis captures snappoints either
in both axes
Solution: Made non-none values of scroll-snap-type on an element trap snappoints
Closed: Accepted
Resolved: TPAC 2015
Issue 83. #
Summary: Adding back elements would make snap-points-x/y exclusive with element-based points
https://lists.w3.org/Archives/Public/www-style/2015Jun/0376.html (rakow)
if we add back the elements value then I'd rather go back to making
the elements/interval options mutually exclusive for simplicity's sake
https://lists.w3.org/Archives/Public/www-style/2015Jul/0035.html (majid)
Are there really no merged use cases?
https://lists.w3.org/Archives/Public/www-style/2015Jul/0453.html (rakow)
Can't think of a single one
Closed: Invalid, pending #82
Issue 90. # Summary: Reference to box, doesn't say whether margin/padding/content box https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html (roc) https://lists.w3.org/Archives/Public/www-style/2014Feb/0815.html (roc) Solution: scroll-snap-area Closed: Accepted
Issue 91. #
Summary: "leading edge" used without definition
https://lists.w3.org/Archives/Public/www-style/2014Jan/0591.html (roc)
https://lists.w3.org/Archives/Public/www-style/2014Oct/0436.html (rakow)
Replaced with "start edge"
Solution: Using "start edge" as term
Closed: Accepted
Issue 92. #
Summary: Define behavior of repeat(0px) / repeat(-1px)
https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html (roc)
https://lists.w3.org/Archives/Public/www-style/2014Oct/0480.html (rakow)
Disallowed zero/negative.
New Issue: Restriction defines an open range, see below
Closed: Accepted
Issue 93. #
Summary: Define valid repeat() values as closed range (include 0)
https://lists.w3.org/Archives/Public/www-style/2015Jul/0036.html
Handle 0 in repeat()
Response: (tab) Use 1px as enforced minimum
https://lists.w3.org/Archives/Public/www-style/2015Jul/0075.html
Solution: Used value floored at UA-specified minimum, recommended at 1px.
Closed: Accepted
Issue 94. #
Summary: What element captures abspos snappoints?
https://lists.w3.org/Archives/Public/www-style/2015Jun/0148.html (smfr)
Snap point capture should follow containing block chain
https://lists.w3.org/Archives/Public/www-style/2015Jun/0376.html (rakow)
Should use containing block chain, but need term...
Closed: Accepted