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

I think the complexity reflects the actual situation, rather than being unnecessary. The existing API, `tabindex`, is overly simplistic in ways that cause problems for authors.

For example, `<input type=text disabled>` could be considered `focusability: default` (although adding a `tabindex` does nothing so it's kind of yet another state) and `accepts-text-input: true`.

In terms of having authors choose between `auto` and `sequential`, it's true that some education will be required that `auto` is likely the right option in most cases.

> I think we do want to allow people to be able to create their own elements that accept text input. Note that, much like list boxes or pop-ups on the Mac, these may not actually be text editable. 

To flip this logic: for the elements which _are_ text editable, how would they opt in to displaying an on-screen keyboard, without using `contenteditable` or one of the existing text input elements? 

If there was a way to do that, should it not opt the element into the sequential focus order automatically?

For the elements which _aren't_ text editable, should they show an on-screen keyboard?

> One obvious example would be a non-editable multicolumn list views that supports typeahead.

Could you expand on that example? I can't picture it from the brief description, sorry.


-- 
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-596380013