Re: [cssom-view] smooth scroll on focus()?

On Tue, Mar 8, 2016 at 2:25 PM, Simon Pieters <simonp@opera.com> wrote:

> On Thu, Mar 3, 2016 at 7:19 PM, Rick Byers <rbyers@chromium.org> wrote:
>>
>> CSSOM View scroll-behavior says: "The scroll-behavior property specifies
>>> the scrolling behavior for a scrolling box, when scrolling happens due to
>>> navigation or CSSOM scrolling APIs. Any other scrolls, e.g. those that
>>> are
>>> performed by the user, are not affected by this property".  To me this
>>> suggests that if the user agent scrolls as a result of a call to
>>> Element.focus(), that scroll-behavior should not be respected.
>>>
>>> Is that intentional?  It seems unfortunate (eg. for accessibility) that
>>> it's possible to get a smooth scroll to an element via
>>> Element.scrollIntoView, but not if you also want the element to be
>>> receive
>>> focus in the process.
>>>
>>
> It's not really intentional. The intention was to have this property not
> affect mousewheel scrolls, keyboard downarrow scrolls, or touchscreen swipe
> scrolls. I think I didn't properly consider moving focus.
>
>
> Perhaps scrollIntoView should now return a promise (or ScrollOptions
>>> should take a callback) so that an action like 'focus' can be performed
>>> when the scroll animation completes?
>>>
>>
> On Sat, 05 Mar 2016 01:23:14 +0100, Rob Dodson <robdodson@google.com>
> wrote:
>
> Possibly related is the spec for sequential focus navigation starting point
>> <
>> https://html.spec.whatwg.org/multipage/interaction.html#sequential-focus-navigation-starting-point
>> >
>> which
>> will move focus based on a user action such as clicking somewhere in the
>> page near a focusable element or when the user clicks on a named anchor.
>> If
>> I were to call element.scrollIntoView on a focusable element, it would be
>> great if either that element were to then automatically gain focus when
>> the
>> scroll animation is complete, or (if that element is not focusable)
>> pressing tab would move to the next nearest focusable element based on the
>> rules in sequential focus navigation starting point.
>>
>
> Alternatively we could extend focus() to take a ScrollIntoViewOptions
> dictionary as argument? It's not clear to me why you would want the element
> to only gain focus when the animation completes, as opposed to immediately.
> Consider if you moved focus to a text field and the user starts typing
> while the animation is still ongoing.
>
> We could add promises also, but are there other use cases for that other
> than wanting to move focus and smooth scroll together?
>
> I think scrollIntoView() shouldn't by itself focus the element you
> scrolled into view. I could be convinced that it should move the focus
> navigation starting point.
>
> If you could file an issue at https://github.com/whatwg/html/issues we
> can discuss extending focus() with the HTML folks.
>

Yeah, agreed that focus taking a ScrollBehavior makes the most sense - filed
<https://github.com/whatwg/html/issues/834> (though I think CSS
scroll-behavior should probably also apply, right?).


> cheers
> --
> Simon Pieters
> Opera Software
>