-
Notifications
You must be signed in to change notification settings - Fork 791
Expand file tree
/
Copy pathissues-by-issue.html
More file actions
777 lines (770 loc) · 63.4 KB
/
issues-by-issue.html
File metadata and controls
777 lines (770 loc) · 63.4 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
6
8000
5
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
<!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
93D4
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(<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 <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/2013
8096
Aug/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 href='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 behavior (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 behavior 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
133E
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'
8D6C
;>#</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: Accepted</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 targeting 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-st
7E54
yle/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>