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