8000 csswg-drafts/css-scroll-snap-1/issues-by-issue.html at 98f34c8f004304aa599bd9600e7a19424508c6d8 · w3c/csswg-drafts · GitHub
Skip to content

issues-by-issue.html

Latest commit

 

History

History
777 lines (770 loc) · 63.4 KB

issues-by-issue.html

File metadata and controls

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