# CSS Scroll Snapping Level 1 Disposition of Comments for 2015-03-26 WD

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:

- Accepted or Rejected and positive response
- Rejected and no response
- Rejected and negative response
- Deferred
- Out-of-Scope or Invalid and not verified

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.

## Scroll Snapping Geometry

    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

## Scroll Snapping Triggers

    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

## Syntax and Property Interactions

    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

## Scroll Snapping Behavior

    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.

## Enabling Element-based Snappoints

    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

## Errors

    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