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

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.
   https://drafts.csswg.org/css-logical-props/#logical-shorthand-keyword

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
default):
   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):
   https://drafts.csswg.org/css-align/

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:
   https://drafts.csswg.org/css-scroll-snap/#snap-type

~fantasai and TJ

Received on Wednesday, 20 January 2016 02:22:57 UTC