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

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

From: Simon Pieters <simonp@opera.com>
Date: Tue, 08 Mar 2016 20:25:13 +0100
To: "Rick Byers" <rbyers@chromium.org>, "Rob Dodson" <robdodson@google.com>
Cc: "www-style@w3.org" <www-style@w3.org>, "Alice Boxhall" <aboxhall@chromium.org>
Message-ID: <op.yd0tkbunidj3kv@simons-macbook-pro.local>
> 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.

cheers
-- 
Simon Pieters
Opera Software
Received on Tuesday, 8 March 2016 19:25:47 UTC

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