Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Firefox] Inert scrollable nodes #31

Open
valdrinkoshi opened this issue Oct 11, 2016 · 6 comments
Open

[Firefox] Inert scrollable nodes #31

valdrinkoshi opened this issue Oct 11, 2016 · 6 comments

Comments

@valdrinkoshi
Copy link
Collaborator

Firefox will add to the tab order nodes with overflow: auto|scroll and enough content to be scrollable (this is done so the user can scroll the contents with the keyboard) - see http://jsbin.com/kupijuj/1/edit?html,output.
The polyfill should take this into account by setting tabindex=-1 to such elements, otherwise there will be an extra tab for each of such nodes.

@alice
Copy link
Member

alice commented Oct 11, 2016

This is challenging - we'll now have to get the computed style for every element we visit, which will force a style recalc and potentially layout each time.

@valdrinkoshi
Copy link
Collaborator Author

Well, we could unconditionally set tabindex=-1 to all of them w/o checking for the computed style, but yeah it would still be heavy 😞

@rodneyrehm
Copy link

According to focusable elements compatibility table there are two CSS properties that might make an element keyboard focusable:

  • user-modify: read-write in Blink, WebKit and MS Edge
  • overflow: auto|scroll in Gecko

If you also consider script/pointer focusable elements, you're in for a few more surprises.

Since CSS selectors can't target CSS properties, these elements cannot be found by way of document.querySelectorAll(). You'd have to walk the entire DOM and examine every node's computed style. This is way more expensive than qSA. I've implemented this approach in ally.query.tabbable in order to come as close to any given browser's behavior as possible.

Depending on the accuracy with which the inert polyfill should identify elements, I'd like to suggest using ally.query.focusable or ally.query.tabbable, instead of rolling your own. But honestly, I don't think that you should do either. Making developers add the tabindex attribute to elements that are focusable seems like a fair trade-off for WICG/inert.

Maybe we should talk about a separate WICG initiative to surface the internal tabindex focus flag to be used in qSA as :focusable and :tabbable?

@alice
Copy link
Member

alice commented Oct 26, 2016

Ok, hacky idea for now: what if we just add another CSS rule to make things inside [inert] overflow: hidden !important; and user-modify: none !important?

@valdrinkoshi
Copy link
Collaborator Author

That would cause a resize on elements that have the scrollbar (on windows), but yeah that would solve the issue..

@alice
Copy link
Member

alice commented Oct 26, 2016

(Unless someone has a more-specific !important rule for those things, but honestly who does that...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants