paradox issue when "tabindex" is used together with "display: none/contents" or "visibility: hidden"

[Zhang-Junzhi]

Generally speaking, an element that does't generate a box or generate an invisible box shouldn't participate in sequential focus navigation.

And I've tested Firefox and Chrome, and found no interoperability issue in this regard(Both of them work this way).

But in some cases a designer might want to focus such an element, I encountered this kind of issue.

I was writing a menu with menuitems in multiple levels, each menuitem is designed to be focusable by tab, and I wanted to show or hide a menuitem based on whether it's focused and its parent is hovered.

.level-1-menuitem
{
	display: none;
	...
}

.level-1-menuitem:hover,
.level-1-menuitem:focus,
.level-1-menuitem:has(.level-2-menuitem:focus)
{
	display: block;
}

However, as mentioned above, this doesn't work, browsers(at least the two mainstream browsers) just ignore tabindex on any hidden menuitems.

I have no clue how to resolve this issue elegantly, and since tabindex is on the HTML side, I don't even know where is the more appropriate place to file this issue, so I decide to file the issue on both the two projects. Hope you won't mind it.

[tabatkins]

The issue is that there's simply nothing there to be focused; the whole point of focusing is to visually indicate where your current point-of-attention is, which will respond to keyboard events/etc. Thus, focusing something that is just completely not rendered at all (and which will not respond to keyboard events/etc) doesn't make much sense.

The standard way to achieve the effect you're talking about is to fake-hide the elements you want to be focusable-but-not-currently-displayed by making them position:absolute and positioning them off-screen, then reverting them to normal display on :focus.

[emilio]

Also note that that :has(.level-2-menuitem:focus) is invalid in sheets and no browser would treat that declaration as valid.

[Zhang-Junzhi]

Thanks you both for your replies and suggestions.

Maybe "position: aboslute;" is probably the easiest way to resolve the issue, but, personally I feel it kinda hacky. Is there any possibility to define a new value that intuitively makes an element invisible while is still keyboard/event responsive.

Just my personal feeling of such usage, it's fine to just let it be(I have no strong opinion on usage of "position: aboslute;", actually still love it while feeling it hacky).

Ah, the above CSS code was roughly used for demostrating a solution which might probably work in future, so I wrote :has. BTW, I am a guy who has a big interest for trying leading edge and habitually just even write things that don't cater to status quo. :P

[SelenIT]

If we treat elements that have no rendered box “not rendered at all” and thus don’t allow them to react to keyboard events, maybe it would make sense to disallow them to have visible content as well? Currently, it looks very strange when an element (e.g. a button with display:contents) visually produces a perfectly visible and interactive (through mouse/touch) control, but this control can’t get focused because implementation-wise it’s “not rendered at all”. Maybe for all interactive control display:contents should be treated as none then, to avoid this nonsense?

However, I’d prefer it the other way around: if an interactive DOM element has any visible and activatable part of the element subtree and has a tabindex property, it should become able to get a “virtual” focus state. This focus state would be invisible by itself, but should affect the styles of element’s descendants (e.g. button:focus would do nothing, but button:focus span would apply). After all, in the DOM the concept of focus state is the characteristics of the DOM element itself, not its style, and CSS shouldn’ change this aspect of behavior except removing the element from all presentations in case of display:none.

Anyway, the current really paradoxical situation when we effectively can have visible and interactive “nothing at all” feels like a bug either in spec or in implementation. I’d be happy with either resolution of this “paradox”.

[Zhang-Junzhi]

What @SelenIT said seems to make senses to me. tabindex seems more of a DOM concept.