Re: [cssom-view] scope of the 'scroll-behavior' property

On Thu, 22 May 2014 10:52:36 +0900, L. David Baron <dbaron@dbaron.org>  
wrote:

> I'm a little concerned about the scope of the 'scroll-behavior'
> property defined in
> http://dev.w3.org/csswg/cssom-view/#smooth-scrolling:-the-%27scroll-behavior%27-property
>
> It seems like this starts from the reasonable premise of
> categorizing scrolling into three groups:
>
>  (1) scrolling done by a user scrolling action (which is
>      intentionally not influenced by any mechanisms in the spec, but
>      controlled by the OS defaults and user settings)
>
>  (2) scrolling that happens from navigation (e.g., navigating to a
>      named anchor)
>
>  (3) scrolling that happens through scrolling APIs.
>
> This spec adds ScrollOptions parameters to a number of APIs (such as
> window.scroll, window.scrollBy, window.scrollTo,
> element.scrollIntoView, element.scrollTop, element.scrollLeft) to
> address case (3): http://dev.w3.org/csswg/cssom-view/#scrolloptions
>
> The scroll-behavior property, on the other hand, says it covers both
> (2) and (3).
>
> First, the spec doesn't seem to say how the two interact:  for the
> methods that have ScrollOptions parameters, which of the
> 'scroll-behavior' or ScrollOptions wins?

It does, see http://dev.w3.org/csswg/cssom-view/#perform-a-scroll

However, I'm open to changing the default from "auto" to "instant" and  
also maybe removing the "auto" value from the API.

> I tend to think that I'd prefer the answer that 'scroll-behavior'
> simply doesn't affect case (3); thus an author changing
> 'scroll-behavior' in order to affect case (2) doesn't end up
> accidentally affecting case (3) as well.  It seems odd to have an
> API whose default behavior is changed by a CSS property but that can
> override the behavior -- the CSS property in question feels not very
> different from a global variable on the window object.
>
> On the other hand, I could imagine an author using 'instant' because
> they want a particular container that contains discrete items never
> to scroll smoothly.  But that case seems better handled by scroll
> snapping, since it should also affect case (1).
>
> Maybe there's some more useful interaction between the two ways of
> specifying the scroll behavior, though?
>
> (Also, that's a horrible named anchor at the start of this message!)

I'll fix that as part of moving to Bikeshed. :-)

-- 
Simon Pieters
Opera Software

Received on Friday, 23 May 2014 07:42:23 UTC