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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

fantasai
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

Reply | Threaded
Open this post in threaded view
|

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

Sebastian Zartner-3
On 24 November 2015 at 23:31, fantasai <[hidden email]> wrote:

> 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...

I agree that 'scroll-snap' should rather be a shorthand for
'scroll-snap-align' and 'scroll-snap-area' and probably also for
'scroll-snap-padding'.

As the strictness and the axis are connected and I assume they won't
get changed that often once set, I'd rather keep the current
definition of 'scroll-snap-type' and not add longhands for it.
Though if people like to have longhands, I'd prefer them to have the
shorthand as prefix. This makes it easier to identify their relation.
E.g. if 'scroll-snap-type' is the shorthand, the longhands could be
something like 'scroll-snap-type-capture' and 'scroll-snap-type-axis'.

To me the difference between the 'both' and 'point' values is not
clear yet, or more precisely the difference between two 1D snap
positions vs. one 2D snap position.
So assuming those values could be removed, the property could also be
split up in two, one for each axis. So we'd have
'scroll-snap-type-block' and 'scroll-snap-type-inline'.

Sebastian

Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Tue, Dec 8, 2015 at 5:05 AM, Sebastian Zartner
<[hidden email]> wrote:
> To me the difference between the 'both' and 'point' values is not
> clear yet, or more precisely the difference between two 1D snap
> positions vs. one 2D snap position.
> So assuming those values could be removed, the property could also be
> split up in two, one for each axis. So we'd have
> 'scroll-snap-type-block' and 'scroll-snap-type-inline'.

I'd love to know what we could improve in
<https://drafts.csswg.org/css-scroll-snap/#snap-dimensions> to make
this clearer.  They can't be merged, as they do two rather different
things.

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Sebastian Zartner-3
On 9 December 2015 at 19:36, Tab Atkins Jr. <[hidden email]> wrote:

>
> On Tue, Dec 8, 2015 at 5:05 AM, Sebastian Zartner
> <[hidden email]> wrote:
> > To me the difference between the 'both' and 'point' values is not
> > clear yet, or more precisely the difference between two 1D snap
> > positions vs. one 2D snap position.
> > So assuming those values could be removed, the property could also be
> > split up in two, one for each axis. So we'd have
> > 'scroll-snap-type-block' and 'scroll-snap-type-inline'.
>
> I'd love to know what we could improve in
> <https://drafts.csswg.org/css-scroll-snap/#snap-dimensions> to make
> this clearer.  They can't be merged, as they do two rather different
> things.

Examples explaining the differences would help.
For the description and the examples given for 2D snap positions I'd
imagine having two 1D snap positions for each axis to work the same.

After rereading the spec. I guess what is actually meant is 'axis
snapping' vs. 'point snapping'. The difference would be that for axis
snapping the scroll snapping can happen along the whole *axis*, while
for point snapping it can only happen at that specific *point*. If
that's the case, I suggest to rename 1D snap positions and 2D snap
positions accordingly to clarify that difference.

Sebastian

Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Sun, Dec 13, 2015 at 1:31 PM, Sebastian Zartner
<[hidden email]> wrote:

> On 9 December 2015 at 19:36, Tab Atkins Jr. <[hidden email]> wrote:
>>
>> On Tue, Dec 8, 2015 at 5:05 AM, Sebastian Zartner
>> <[hidden email]> wrote:
>> > To me the difference between the 'both' and 'point' values is not
>> > clear yet, or more precisely the difference between two 1D snap
>> > positions vs. one 2D snap position.
>> > So assuming those values could be removed, the property could also be
>> > split up in two, one for each axis. So we'd have
>> > 'scroll-snap-type-block' and 'scroll-snap-type-inline'.
>>
>> I'd love to know what we could improve in
>> <https://drafts.csswg.org/css-scroll-snap/#snap-dimensions> to make
>> this clearer.  They can't be merged, as they do two rather different
>> things.
>
> Examples explaining the differences would help.
> For the description and the examples given for 2D snap positions I'd
> imagine having two 1D snap positions for each axis to work the same.
>
> After rereading the spec. I guess what is actually meant is 'axis
> snapping' vs. 'point snapping'. The difference would be that for axis
> snapping the scroll snapping can happen along the whole *axis*, while
> for point snapping it can only happen at that specific *point*. If
> that's the case, I suggest to rename 1D snap positions and 2D snap
> positions accordingly to clarify that difference.

As far as I can tell, that's what we wrote in the linked section?  The
note in the 1D section is pretty explicit about the difference between
2D and double-1D: double-1D can horizontally snap to one element, but
vertically snap to a different element entirely, while 2d snapping
always snap both axises to a single element.

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Sebastian Zartner-3
On 15 December 2015 at 00:26, Tab Atkins Jr. <[hidden email]> wrote:

> On Sun, Dec 13, 2015 at 1:31 PM, Sebastian Zartner
> <[hidden email]> wrote:
>> On 9 December 2015 at 19:36, Tab Atkins Jr. <[hidden email]> wrote:
>>>
>>> On Tue, Dec 8, 2015 at 5:05 AM, Sebastian Zartner
>>> <[hidden email]> wrote:
>>> > To me the difference between the 'both' and 'point' values is not
>>> > clear yet, or more precisely the difference between two 1D snap
>>> > positions vs. one 2D snap position.
>>> > So assuming those values could be removed, the property could also be
>>> > split up in two, one for each axis. So we'd have
>>> > 'scroll-snap-type-block' and 'scroll-snap-type-inline'.
>>>
>>> I'd love to know what we could improve in
>>> <https://drafts.csswg.org/css-scroll-snap/#snap-dimensions> to make
>>> this clearer.  They can't be merged, as they do two rather different
>>> things.
>>
>> Examples explaining the differences would help.
>> For the description and the examples given for 2D snap positions I'd
>> imagine having two 1D snap positions for each axis to work the same.
>>
>> After rereading the spec. I guess what is actually meant is 'axis
>> snapping' vs. 'point snapping'. The difference would be that for axis
>> snapping the scroll snapping can happen along the whole *axis*, while
>> for point snapping it can only happen at that specific *point*. If
>> that's the case, I suggest to rename 1D snap positions and 2D snap
>> positions accordingly to clarify that difference.
>
> As far as I can tell, that's what we wrote in the linked section?  The
> note in the 1D section is pretty explicit about the difference between
> 2D and double-1D: double-1D can horizontally snap to one element, but
> vertically snap to a different element entirely, while 2d snapping
> always snap both axises to a single element.

At least for me it is not clear enough. At least mentioning the word
'point' within the 2D snap position section could clarify things a bit
more. Also, as mentioned before, code samples and/or drawings showing
the differences would make it more obvious.

Sebastian

Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Mon, Dec 14, 2015 at 11:44 PM, Sebastian Zartner
<[hidden email]> wrote:
> At least for me it is not clear enough. At least mentioning the word
> 'point' within the 2D snap position section could clarify things a bit
> more.

All right, I'll see what I can do.

> Also, as mentioned before, code samples and/or drawings showing
> the differences would make it more obvious.

Yeah, we def need tons more examples.

~TJ

Reply | Threaded
Open this post in threaded view
|

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

fantasai
In reply to this post by Sebastian Zartner-3
On 12/13/2015 01:31 PM, Sebastian Zartner wrote:

> On 9 December 2015 at 19:36, Tab Atkins Jr. <[hidden email]> wrote:
>>
>> On Tue, Dec 8, 2015 at 5:05 AM, Sebastian Zartner
>> <[hidden email]> wrote:
>>> To me the difference between the 'both' and 'point' values is not
>>> clear yet, or more precisely the difference between two 1D snap
>>> positions vs. one 2D snap position.
>>> So assuming those values could be removed, the property could also be
>>> split up in two, one for each axis. So we'd have
>>> 'scroll-snap-type-block' and 'scroll-snap-type-inline'.
>>
>> I'd love to know what we could improve in
>> <https://drafts.csswg.org/css-scroll-snap/#snap-dimensions> to make
>> this clearer.  They can't be merged, as they do two rather different
>> things.
>
> Examples explaining the differences would help.
> For the description and the examples given for 2D snap positions I'd
> imagine having two 1D snap positions for each axis to work the same.
>
> After rereading the spec. I guess what is actually meant is 'axis
> snapping' vs. 'point snapping'. The difference would be that for axis
> snapping the scroll snapping can happen along the whole *axis*, while
> for point snapping it can only happen at that specific *point*. If
> that's the case, I suggest to rename 1D snap positions and 2D snap
> positions accordingly to clarify that difference.

Hi Sebastian,
Tab and I just went through the spec and renamed these terms as you
suggested, and in general tried to clarify what they meant. Please
take a look and let us know if you have further suggestions for
improvement.
   https://drafts.csswg.org/css-scroll-snap/#snap-type

Thanks!

~fantasai

Reply | Threaded
Open this post in threaded view
|

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

Sebastian Zartner-3
On 16 January 2016 at 00:41, fantasai <[hidden email]> wrote:

>
> On 12/13/2015 01:31 PM, Sebastian Zartner wrote:
>>
>> On 9 December 2015 at 19:36, Tab Atkins Jr. <[hidden email]> wrote:
>>>
>>>
>>> On Tue, Dec 8, 2015 at 5:05 AM, Sebastian Zartner
>>> <[hidden email]> wrote:
>>>>
>>>> To me the difference between the 'both' and 'point' values is not
>>>> clear yet, or more precisely the difference between two 1D snap
>>>> positions vs. one 2D snap position.
>>>> So assuming those values could be removed, the property could also be
>>>> split up in two, one for each axis. So we'd have
>>>> 'scroll-snap-type-block' and 'scroll-snap-type-inline'.
>>>
>>>
>>> I'd love to know what we could improve in
>>> <https://drafts.csswg.org/css-scroll-snap/#snap-dimensions> to make
>>> this clearer.  They can't be merged, as they do two rather different
>>> things.
>>
>>
>> Examples explaining the differences would help.
>> For the description and the examples given for 2D snap positions I'd
>> imagine having two 1D snap positions for each axis to work the same.
>>
>> After rereading the spec. I guess what is actually meant is 'axis
>> snapping' vs. 'point snapping'. The difference would be that for axis
>> snapping the scroll snapping can happen along the whole *axis*, while
>> for point snapping it can only happen at that specific *point*. If
>> that's the case, I suggest to rename 1D snap positions and 2D snap
>> positions accordingly to clarify that difference.
>
>
> Hi Sebastian,
> Tab and I just went through the spec and renamed these terms as you
> suggested, and in general tried to clarify what they meant. Please
> take a look and let us know if you have further suggestions for
> improvement.
>   https://drafts.csswg.org/css-scroll-snap/#snap-type

Hi fantasai, hi Tab,

it reads much clearer now. Thank you!

Sebastian

Reply | Threaded
Open this post in threaded view
|

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

Matt Rakow
In reply to this post by fantasai
> -----Original Message-----
> From: fantasai [mailto:[hidden email]]
> Sent: Tuesday, November 24, 2015 2:32 PM
> To: [hidden email]
> 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
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Wed, Apr 6, 2016 at 5:07 PM, Matt Rakow <[hidden email]> wrote:
> 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.

No it's not. Been defined in
<https://drafts.csswg.org/css-scroll-snap/#scroll-snap-alignment> for
a while (look for the paragraph starting "If the element's scroll
container is point-snapping...")

> 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.

I don't agree; I think it's reasonable to 2d-snap with mandatory in
one axis and proximity in the other.  It just means that your
proximity axis only tries to snap to the same point the mandatory axis
has snapped to; if it's not close, that axis just floats around.

(That said, it's not a huge loss to disallow it.)

> 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):

Yeah, it's easy - you just split the axis keywords that allow two
affinities into a separate grammar branch that allow that:

none | [ proximity | mandatory ] || [ x | y | block | inline ] | [
proximity | mandatory ]{1,2} || [ both | point ]

And then specify the defaulting rules for the new grammar branch: if
you specify both/point and only one affinity, the other defaults to
the same; if you specify no affinities, they both default to
'proximity'; if you specify two affinities and no axis, it defaults to
'both'.

> scroll-snap-type: mandatory proximity; /* mandatory in x axis, proximity in y */
> scroll-snap-type: point mandatory; /* mandatory point snapping */

Yes.

> scroll-snap-type: point mandatory proximity; /* invalid! */

I think that's fine, but whatever; if "point" moves to the
single-affinity group, yeah, this is invalid.

> scroll-snap-type: mandatory; /* mandatory in both x and y axes (but not point snapping) */

Right now the spec defaults a missing axis to either the scrolling
axis (if only one axis is scrollable) or the block axis (otherwise).
So a single affinity should still default that way.

~TJ