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

The previous proposals dropped programmatically focusable, as you pointed out: hence three rather than four (`default`, `keyboardable`, `non-keyboardable`, or some variation thereof). 

I make the split between `keyboardable` and `non-keyboardable` slightly differently:

- `sequential` is close to `keyboardable`, but just says "trust me and always put this in the tab order" (i.e. `<select>` and other special cases - identical in behaviour to `tabindex=0`)
   - I could be convinced to drop this if we want to rule out authors determining that something should always be sequentially focusable regardless of platform conventions.
- `auto` is kind of a conflation of the two non-default options, where it is up to the UA to determine whether it wants to include something in the tab order or not, presumably based on `accepts-text-input` or whatever other heuristics make sense in context.

`accepts-text-input` would also presumably opt an element into other things like showing an on-screen keyboard when focused and always matching `:focus-visible` when focused, which is why I think it's a separate concept. Certainly splitting it out makes naming clearer, per my proposal in the previous comment.

I guess it boils down to whether we want people to be able to create their own text-editable elements (via listening for keyboard events on an otherwise ordinary element), or require everything to either use `contenteditable` or be an existing text-editable element (in which case we don't need a "text-editable" concept since we'll be able to tell based on that restriction which elements are text editable).

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