issues-by-issue.txt

Draft:    http://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
Title:    CSS Scroll Snapping Level 1
Shortname: css-scroll-snap-1

  Use case: scrolling through photo album, want to snap each image to center of screen,
    or slightly offset from center.
  https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html (Seattle F2F)

    Use case: scrolling through photo album, want to present it "film-strip" style N at a time.
  https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html (Seattle F2F)

    Use case: scrolling a large map, want to snap cities to the center when they're close, or slightly offset from center.
  https://lists.w3.org/Archives/Public/www-style/2014Feb/0607.html (Seattle F2F)

----
=========================== 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 beahvior (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 behaviour 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 targetting 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
----