Dated Draft: http://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
Editor's Draft: http://dev.w3.org/csswg/css-scroll-snap-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
Issu 41. Summary: Add "none" value to scroll-snap-points-x/y https://lists.w3.org/Archives/Public/www-style/2013Dec/0058.html (roc) Given element-based snapping, need ability to say "none" in scroll-snap-points-x/y https://lists.w3.org/Archives/Public/www-style/2014Oct/0474.html (roc) Add "none" value to scroll-snap-points-x/y https://lists.w3.org/Archives/Public/www-style/2014Oct/0480.html (rakow) Added. Closed: Accepted
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