W3C home > Mailing lists > Public > www-style@w3.org > April 2016

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 8 Apr 2016 11:01:19 -0700
Message-ID: <CAAWBYDDLNgitPe7k_LdrHOdKrG3KGDNwtuTB2pC+C-rFDLGYjQ@mail.gmail.com>
To: Matt Rakow <marakow@microsoft.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On Wed, Apr 6, 2016 at 5:07 PM, Matt Rakow <marakow@microsoft.com> 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
Received on Friday, 8 April 2016 18:02:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:43 UTC