Re: [w3c/webcomponents] Mechanism for setting the tabindex focus flag without sprouting tabindex attribute? (#762)

> From [this gist](https://gist.github.com/alice/b83a9d315a4aae30aabbe27710e91c52), @alice wrote:
> 
> > I think we can get away with two states, with several caveats.
> > The states would be:
> > `focusable` (or `auto`, or...)
> > `default` (or `unfocusable`, or...)
> > The caveats:
> > `unfocusable` custom elements would still be programmatically focusable.
> 
> So, custom elements set as `unfocusable` would not be in the tab order, but would still achieve focus if the author called the `.focus()` method on the custom element. Correct?

Making custom elements always programmatically focusable doesn't seem like a backwards compatible change to me. During our work to make Safari to iPad load desktop sites, we encountered numerous websites including Microsoft Office 365 that move focus inadvertently(?) to multiple elements before the correct element is focused. Making previously non-programatically focusable element always programmatically focusable has a risk that it would make previously no-op `focus()` call move the focus to the context object and blur the previously focused element. This can result in a wrong element having the focus. We need to come up with some way to mitigate this backwards compatibility risk. I don't that's the kind of compatibility risk we want to take given how many tricky-to-diagnose bugs we've encountered in this area especially in conjunction with iOS's software keyboard & focus scrolling behavior.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/762#issuecomment-689259110