[Firefox] Inert scrollable nodes about inert

[alice]

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]

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]

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]

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]

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

[alice]

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