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

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 19 Jan 2016 18:22:25 -0800
To: Matt Rakow <marakow@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <569EEF61.6050209@inkedblade.net>
On 01/14/2016 11:56 AM, Matt Rakow wrote:
> (1) I also specified that scroll-snap-align with two values maps
> the first value to X axis and the second value to Y axis, rather
> than to the inline and block axes.  This is to avoid the problem
> that scroll-snap-padding and scroll-snap-area were defined in
> physical but scroll-snap-align was defined in logical, which I
> suspect would result in unintended axis mismatch when used across
> various writing modes.
> I also added an open issue to the spec on this topic -- any concerns
> with this approach, or perhaps we should respec to say that all 3
> properties are in logical?  As we've discussed previously there are
> scenarios for both physical and logical (e.g. slideshows vs. document
> pagination), but my gut feel is that physical comprises the majority
> of scenarios.

Well, we do want to make sure that the 'scroll-snap-padding' and
'scroll-snap-margin' are consistent with regular 'padding' and 'margin'.
So those will have to stay physical by default. But we're also planning
to add logical syntax options for the 'margin' and 'padding' shorthands in
the logical properties module, in which case 'scroll-snap-margin/padding'
should also accept such syntax. So ultimately, both coordinate systems
will be expressible in these properties.

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!

Furthermore, not only is the scrolling direction and origin a logical
operation, the scroll snap axis is also, by default, logical: if no axis
is specified, and both are scrollable, we're capturing snap positions
only in the block axis by default (since that's really the most sensible
   https://drafts.csswg.org/css-scroll-snap/#snap-type (bottom of section)

Given all these considerations, we think 'scroll-snap-align' must accept
logical alignment values at the minimum.

We could *also* provide physical alignments as an option, if that seems
to be needed. If so, the grammar would look like

   [ none | start | end | center ]{1,2} |
   [[ none | start-x | end-x | left | right | center-x ] ||
    [ none | start-y | end-y | top | bottom | center-y ]]

(consistent with background-position). However, while this is a clean
expansion point if we need it in the future, I think it's better to
leave them out and guide authors to using logical alignments, since
that's nearly always what's intended. This is also consistent with
what's happening in the Box Alignment module (and Flexbox/Grid Layout):

Note that we *do* recognize that the scrolling axis (as opposed to
scrolling direction) is sometimes more of a physical concern, but the
'scroll-snap-type' property accepts physical axis keywords ( x | y )
as well as logical ones ( block | inline ) for that reason:

~fantasai and TJ
Received on Wednesday, 20 January 2016 02:22:57 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:56 UTC