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

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

From: Rick Byers <rbyers@chromium.org>
Date: Tue, 8 Mar 2016 14:56:39 -0500
Message-ID: <CAFUtAY-K=FZ7uG1T=r0gKRwQfRQVj4DWk==sH=Vz7r=38pMMOg@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: Rob Dodson <robdodson@google.com>, "www-style@w3.org" <www-style@w3.org>, Alice Boxhall <aboxhall@chromium.org>
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 19:57:31 UTC

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