RE: [css-scroll-snap] Splitting scroll-snap-type, shorthanding on scroll container

> -----Original Message-----
> From: fantasai [mailto:fantasai.lists@inkedblade.net] 
> Sent: Tuesday, November 24, 2015 2:32 PM
> To: www-style@w3.org
> Subject: [css-scroll-snap] Splitting scroll-snap-type, shorthanding on scroll container
> 
> The current 'scroll-snap-type' property takes two different, and orthogonal, sets of values:
>    https://drafts.csswg.org/css-scroll-snap/#snap-type

> 
> scroll-snap-type: none | [ proximity | mandatory ] || [ x | y | block | inline | both | point ]
> 
> There are the “strictness” values and the “axis” values.
> 
> We're thinking it would make sense to have a shorthand and two longhands here. The question is, what are they all called?
> 
> I've come up with four ideas so far:
> 
>    a) scroll-snap         -> scroll-snap-type / scroll-snap-axis
>    b) scroll-snap         -> scroll-snap-capture / scroll-snap-axis
>    c) scroll-snap-type    -> scroll-snap-capture / scroll-snap-axis
>    d) scroll-snap-capture -> scroll-snap-type / scroll-snap-axis
> 
> I'm not super keen on any of them and welcome other ideas.
> 
> My main reservation with a) and b) is that 'scroll-snap'
> might be better used as a shorthand for 'scroll-snap-align'
> and 'scroll-snap-area', which are set on descendants of the scroll container... or alternately we may want 'scroll-snap'
> to also reset the 'scroll-snap-padding' property.
> 
> Thoughts on appropriate shorthanding structures and/or names?
> 
> ~fantasai

I've been doing some thinking about this question in combination with the addition of point-based snapping ("2d snapping").  I see a couple issues that need to be addressed:

1. It's possible for an element to only contribute a snap position in one axis via a scroll-snap-align value like "none start".  Since point-based snapping relies on contribution of a complete point, the behavior of these elements in a point-based snapping scroll container is currently undefined.
2. scroll-snap-type currently only allows for definition of a single snap type for a scroll container.  This mades more sense with the syntax of the old WD since all snap coordinates were point-based, but with the new WD's lean toward grid-based snapping that restriction is more artificial.  For grid-based snapping it's not a stretch to imagine snapping mandatorily in the Y axis but proximally in the X axis.
3. The restriction of a single snap type for point-based snapping still makes sense however.  A point-based Y-mandatory X-proximity snapping scroll container must either violate the point-based requirement or treat the X-axis as mandatory.

To satisfy 1, this combination needs to either be defined or the possibility needs to be eliminated via syntax.  The only sane definition I can think of would be:  point-based snapping scroll containers ignore elements that don't contribute a snap position in both axes.  But this isn't a particularly satisfying solution; I would prefer to eliminate the possibility via syntax if possible.

I also think 2 is interesting enough that we should consider enabling the scenario.

Not being a syntax expert myself, is there some clean syntactic way of enforcing one snap type for point-based snapping, while still allowing two snap types for grid-based snapping?  E.g. something like these (I realize these don't fully account for logical properties, just trying to keep the examples simple):

scroll-snap-type: mandatory proximity; /* mandatory in x axis, proximity in y */
scroll-snap-type: point mandatory; /* mandatory point snapping */
scroll-snap-type: point mandatory proximity; /* invalid! */
scroll-snap-type: mandatory; /* mandatory in both x and y axes (but not point snapping) */

Thanks,
-Matt

Received on Thursday, 7 April 2016 00:07:48 UTC