RE: [css-snappoints] Various issues

| Can we change the name of the spec to css-scrollsnap? 
| We don't snap to points, but to edges.

Looks reasonable to me.



| For that reason, I think scroll-snap-points-x/y should be
| renamed to scroll-snap-positions-x/y.

This looks more verbose to me, and not much more informative than the previous one. 

That being said, I was asking myself the question why we needed a new grid-definition language here. I'm in favor of simply reusing the "grid-template" syntax in a "scroll-snap-template" property : this would enable visual editors to be reused, and reuse existing mental models. 

I'm pretty sure that, in a lot of useful cases, we already have to handle the snapped scroll on a grid, and we could therefore even have 

    (1) "scroll-snap: mandatory from-grid(*:*)" which means "use as mandatory snapping-lines all rows and all columns of the computed value of the grid template" 

or 

    (2) variants like "scroll-snap: mandatory none from-grid('start', 'separator', 'end' : *)" which means "use as mandatory horizontal snapping-lines the vertical lines from the grid named 'start', 'separator' or 'end', do not define any vertical snap-mechanism".

A solution like this one would maybe reduce the need for the "descendant-based snapping lines" mechanism you described a bit further in the mail, since you could achieve the same result at the parent level using a grid, which may be simpler to implement than creating deep scroll-snapping dependencies (that may be worth at some point, but we may refrain from including this in L1 in order to make some progress implementation-wise asap).



| scroll-snap-type seems unnecessarily verbose. I suggest we 
| just use scroll-snap.

By convention, "scroll-snap" should be a shorthand for all "scroll-snap-xxxx" properties so this isn't what we want here, I guess. That doesn't mean we don't want a "scroll-snap" property, but it has be usable for defining the positions/templates too.



| I think independent control over vertical and horizontal snapping
| will be very useful. (E.g, vertical scrolling through a list of items, 
| some of which may overflow horizontally.) I propose making 
| scroll-snap a shorthand for scroll-snap-x and scroll-snap-y.

+1



| What should happen when we're currently snapped to an edge and
| that edge moves? (E.g. due to dynamic changes to the 
| scroll-snap-positions-x/y properties, or due to a layout change moving
| an edge induced by an element with scroll-snap-edge?) In proximity
| mode I guess it's OK to just do nothing. But in mandatory mode, I think
| we should re-snap to the nearest snapping edge, or something like that.

Looks reasonable, too. 

The behavior could be undefined (aka platform dependent) for proximity, 
and defined for mandatory (aka always resnap).



| I have a proposal for a scroll-snap-edge property that adds edges of an
| element's margin-box or border-box to the list of allowable snapping 
| positions. I think in most cases this is simpler and more robust than
| scroll-snap-positions-x/y. I would like this, or some version of it, to be
| incorporated into the spec. 
| 
| The details are here: https://wiki.mozilla.org/index.php?title=Gecko:CSSScrollSnapping

+1

Received on Wednesday, 4 December 2013 15:59:13 UTC