W3C home > Mailing lists > Public > www-style@w3.org > March 2016

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

From: Rob Dodson <robdodson@google.com>
Date: Tue, 8 Mar 2016 13:25:45 -0800
Message-ID: <CAJj5OwCg6G5G+LT6Q3aMT1wo0OPi5FWiyEQJnCHcK9e8s+xsLA@mail.gmail.com>
To: Rick Byers <rbyers@chromium.org>
Cc: Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>, Alice Boxhall <aboxhall@chromium.org>
> 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
Received on Tuesday, 8 March 2016 21:32:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:01 UTC