Re: [css-snappoints] Feedback roll-up

On Fri, Jul 3, 2015 at 2:27 AM Robert O'Callahan <robert@ocallahan.org>
wrote:

> On Fri, Jul 3, 2015 at 3:07 AM, Majid Valipour <majidvp@chromium.org>
> wrote:
>
>> I would argue that there should be a way for programmatic scrolling to
>> evade "snap-points" when necessary. Perhaps evading snap points should be
>> default for programmatic scrolls with an option to opt in to snap points!
>> When an application uses a programmatic scrolls to scroll to a specific
>> offset it actually means to scroll to that offset and snap points should
>> not interfere with that. (Element.scrollIntoView and focus are the only
>> exceptions IMO)
>>
>> Changing this behavior breaks long-standing developer expectations of
>> setting scroll offsets and it taking effect (See example below). It also
>> prevents some legitimate usecase such as animating scroll offsets.
>>
>
> I agree.
>
> However, that conflicts with the spec text "If the content changes such
> that the visual viewport would no longer rest on a snap point (e.g. content
> is added, moved, deleted, resized), the scroll offset must be modified to
> maintain this guarantee." It doesn't make sense to allow some DOM APIs to
> violate that invariant but require other content changes to preserve it. If
> a script scrolls away from a snappoint, and then there's an insignificant
> DOM change, what would we do? I suggest we just remove that spec
> requirement; I think it's hard to implement and is likely to produce
> undesirable behavior anyway.
>

Agreed.

If we ensure there is an API for pragmatically causing snap then
applications can use it to cause snap when desired after any scripted
scrolling or any changes that may update layout. This is backward
compatible and allows developers to create the experience they want without
needing to re-implement snap themselves. Perhaps something like:
Element.scrollTo(x,y, 'snap').

There is definitely value to have an API for defining how scroll offset
should be maintained (or not) in response to layout changes but that can be
orthogonal to snap points. In fact, there is another proposal,
css-sticky-scrollbars [1], which tries to achieve the same to address
slightly different use-cases from snap points. It may be best to come up
with something more generic here which can be used in both use-cases.

Majid

[1] https://lists.w3.org/Archives/Public/www-style/2015Jul/0009.html