caridy
commented
5 years ago Few things that were discussed today (@ekashida and myself):
- How to support regular elements to normalize the tabindex? We have two options: polyfill HTMLElement.prototype.tabindex descriptor, or use the patching mechanism in faux-shadow to do this work. Neither of those is trivial.
- How to support custom elements with tabindex=-1? This use a technique that we discussed in the past: if the user is setting the tabindex to -1, we really set it to 0, and then apply the logic described below to place the focus on the proper next/previous focusable elements as a mechanism to skip the focus of the entire subtree of the custom element because the user wants tabindex -1.
- How to support custom element with tabindex=0? If delegatesFocus flag is off, then just set it to 0, but if that flag is on, then you remove the tabindex entirely. Nice trick right?
- How to implement
activeElementin a custom element with delegatesFocus on. We need some investigation to see how the spec works, e.g.: what if you have x-foo x-bar and input, composed via shadow boundaries, and the focus in place on the input, and x-foo has delegatesFocus on, but x-bar doesn't. In this case, what is the value ofthis.template.activeElementin x-foo and x-bar? - How to implement
:focusselector in CSS (in fallback mode, the focus is never really on the custom element, but on a child of it). We can explore focusin/focusout to see if we can add a html attribute that we can use in our css transformer. - How to know in which direction the user is tabbing when a custom element receive the focus? this is need when the user is intending to set the focus to -1 on the custom element, in which case we set it to 0 to control the navigation and place the focus on the next or previous focusable element. (we might need to listen for keyboard interaction etc, another challenge is when the focus is coming from below, shift-tab, the focused element is the last focusable child of the custom element subtree) .
- How to know what is the previous and next focusable element. I found a weird but apparently effective way to do that by making two queries when detecting that the focus should skip the custom element in a particular direction (from the previous bullet point). One query looking for potential focusable elements from document, and another one looking for potential focusable elements from the custom element. It appears that since the query is the same, the result of the second one should be a "segment" of the previous query. If we can identify that segment, and we know the direction that the user is moving, we can them zip thru the proper segment to find the next or previous focusable element that should receive the focus programmatically.
gonzalocordero
Description
Implement
delegatesFocusstatic prop so LWC input focus can skip the custom element container.