-
Notifications
You must be signed in to change notification settings - Fork 81
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
Comments
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. |
Well, we could unconditionally set |
According to focusable elements compatibility table there are two CSS properties that might make an element keyboard focusable:
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 Depending on the accuracy with which the inert polyfill should identify elements, I'd like to suggest using Maybe we should talk about a separate WICG initiative to surface the internal tabindex focus flag to be used in qSA as |
Ok, hacky idea for now: what if we just add another CSS rule to make things inside |
That would cause a resize on elements that have the scrollbar (on windows), but yeah that would solve the issue.. |
(Unless someone has a more-specific |
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.The text was updated successfully, but these errors were encountered: