- From: Rob Dodson <robdodson@google.com>
- Date: Fri, 4 Mar 2016 16:23:14 -0800
- To: Rick Byers <rbyers@chromium.org>
- Cc: "www-style@w3.org" <www-style@w3.org>, Alice Boxhall <aboxhall@chromium.org>
- Message-ID: <CAJj5OwCpXTLaw1=oCouKDB1dXN7zRK4yu1LAEg=+D9bQ5fPEvw@mail.gmail.com>
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. 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. > > 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? > > Thanks, > Rick >
Received on Monday, 7 March 2016 08:31:21 UTC