Re: [css-snappoints] [css-scroll-snap] Summary of latest updates 1/13

On 01/20/2016 06:55 AM, Matt Rakow wrote:
>> As far as 'scroll-snap-align' goes, I think in most cases the
>> important consideration is the logical direction, not the
>> physical one. Consider bidi cases: if you're snapping a side
>> edge, it's almost always going to be the start edge you care
>> about, not the left/right edge specifically, because that's
>> what matches up to the direction of scrolling. Similarly for
>> vertical text: if you're snapping to the top edge in horizontal
>> text, you definitely want to be snapping to the block-start
>> edge in vertical writing modes, not to the block-end edge in
> > any case!
>
> This assumes the content you are snapping is primarily text.
> On the contrary, the most common scenarios are not text --
> hero flippers (e.g. MSN.com), product catalogs (e.g. Amazon.com),
> filmstrips (e.g. Flickr.com), etc. are more prevalent by far.
> Even many scenarios which seem to be primarily text (e.g.
> address book on a phone) typically don't change orientation
> on writing mode, preferring to maintain the ergonomics of a
> particular scrolling direction.

Sure, they might not change *orientation* by writing mode, but
I would expect them to change *direction* (within the axis) by
writing mode. Certainly the origin already changes by writing mode!
If you are in an RTL document, a horizontal scroller will start
on the right, not the left.

(Note also that Flex and Grid are fully logical: if you ask for
rows, you will increase in the block axis, i.e. downward in
horizontal writing modes, leftward for vertical-rl, and rightward
for vertical-lr. Anyone designing a consistent physical layout
will need to be careful around mixed writing modes, since a lot
of CSS layout is fundamentally logical...)

> To clarify, the scenario I am concerned about is something like this:
>
> .horizontalFlipperWidget {
>      overflow-x: scroll;
>      scroll-snap-align: center none;
>      scroll-snap-type: mandatory;
> }
>
> This is the number one scenario for snap points, I'd like
> it to not break by default in vertical writing mode.

If you write it as
   .horizontalFlipperWidget {
      overflow-x: scroll;
      scroll-snap-align: center;
      scroll-snap-type: mandatory;
   }
or alternately as
   .horizontalFlipperWidget {
      overflow: scroll;
      scroll-snap-align: center;
      scroll-snap-type: mandatory x;
    }
then that will work regardless of writing mode:
   * if only one keyword is given for an alignment, it is doubled
   * by default, we snap in the scrollable axis if there's only one;
     given overflow-x, this will be the x axis
   * if an axis is specified on scroll-snap-type, we only snap that axis

> Definitely agree it will be good to ensure both coordinate
> systems are expressible.  Could this keyword also be used
> for scroll-snap-align as a way to enable both?

We'd go with using different words for physical vs logical values:
top/left/bottom/right vs start/end, as we mentioned. See e.g. the
margin-block-start property and the L4 background-position syntax.
(Also, "logical top left" is weird... and English-centric.)

~fantasai

Received on Wednesday, 20 January 2016 15:30:30 UTC