Re: CSS properties for snapping during scrolling

On Thu, Aug 15, 2013 at 5:20 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Fri, Aug 16, 2013 at 10:57 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>>
>> Proposal's good, except for the tie to physical directions.
>>
>> scroll-snap-[vertical|horizontal] should be scroll-snap-[block|inline]
>
>
> That's logical, but it sounds very confusing for authors :-(.
>
>> scroll-snap-edge should have values of: "none | [ margin-block-start
>> || margin-inline-start || block-start || inline-start ]".  Maybe add
>> just "margin-start || start" to it as well, which sets the edges in
>> both axises.
>
>
> Likewise. I think authors aren't going to understand what "block" and
> "inline" mean in this context. "block-start" is much harder to understand
> than "top".

Somewhat harder to understand, yes, but actually correct and useful.
These names will start showing up more and more as we introduce things
that need to refer to logical directions, so this won't be a one-off.

> Could we support both physical and logical properties and values here? I
> think we could. So scroll-snap-edge values could be "none | [ left ||
> margin-left || top || margin-top || inline-start || margin-inline-start ||
> block-start || margin-block-start ]". (I've wondered whether
> "end"/"right"/"bottom" values would be useful as well, but I haven't though
> of a need yet.)

I see no reason why you *ever* want physical snapping.  When you would
want an element to snap in the block axis in a horizontal language,
but in the inline axis in a vertical language?  That's what "vertical"
means, after all.

>> scroll-snap needs an additional value that abruptly jumps between the
>> snap points, rather than allowing smooth scrolling and then adjusting
>> to a snap point (this is used by things like spreadsheets).
>
> Does this make sense for touch panning? I kinda doubt it does. Maybe instead
> whether we abruptly jump between snap points should be up to the UA and
> depend on the scroll mechanism?

Yes, of course it makes sense.  There's no difference between a touch
pan, a trackpad pan, and a mousewheel, but all three of those trigger
this sort of behavior in, say, Google Spreadsheets.

For example, on my Pixel, there's no earthly reason to distinguish
between a touch scroll and a two-finger trackpad scroll.  (At least,
as long as all you're doing is scrolling.  Things that *want* special
touch controls, like Google Maps, are a different case, but I don't
think that's relevant here.)

>> I'd add an additional property for setting explicit snap points in
>> addition to the implicit points coming from the children, probably
>> with a repetition syntax so you can set up a snap point every 100px or
>> whatever.
>
> That makes sense.

~TJ

Received on Friday, 16 August 2013 00:29:30 UTC