Re: [w3c/webcomponents] tabIndex -1 behaves differently on non-Custom Elements (#774)

@freshp86 

> Just a thought about this: Perhaps providing a way for consumers of a component to modify this behavior would alleviate this problem? Even if an author created a "bad" component, consumers could "fix" that behavior on their end, for example <my-element delegates-focus>...</my-element>?

I don't think we want this, it is basically inversion of control on something that is an internal implementation detail.

@annevk 

> @caridy there's a difference between enabling elements inside a shadow tree being "tab-focusable" and letting that tree override the tab order of the light tree, no?

That's a very interesting question. I haven't play much with tab-focusable elements in light dom, maybe @davidturissini and @SiTaggart has some opinions here, but my intuition here is:

* the shadow tree does not dictate the order of the light tree tab order (e.g.: `<x-foo><input tabindex=2 /><x-foo>` might be the first focusable element from x-foo, even though x-foo might have another tab-focusable element with tabindex=1)
* the host dictates whether or not the tab-focusable elements in the light dom are reachable (e.g.: tabindex=-1 on the host indicates that those elements, along with the shadow tree elements are not part of the tab navigation.

Side note: in our platform, this is not a problem because we intentionally only allow tabindex=0 and -1 in all authored web components, and only high-privilege code (usually app level code) can bend that rules (e.g.: panels and such that might require some specific 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/774#issuecomment-441074151