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

>
> We could add promises also, but are there other use cases for that other
> than wanting to move focus and smooth scroll together?


I could imagine wanting to know when the animation is done. A couple use
cases that pop to mind.. if I have some other expensive process running at
the same time I could pause and then resume it once the animation finishes.
Or I may want to change the UI once the user lands on the element (perhaps
triggering an animated tooltip or something). I guess any time there's some
sort of animation going on in my app I want to have a way to know when it
finishes so I can sequence actions

On Tue, Mar 8, 2016 at 11:56 AM, Rick Byers <rbyers@chromium.org> wrote:

> 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
>>
>
>