1553549 - display contents elements can't get focus

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P3)

Description

[François REMY]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763

Steps to reproduce:

https://wptest.center/#/c0e1u8
click on the first text box, then press TAB.

Actual results:

the focus is on the link.

Expected results:

the focus is on the text box.

Comment 1

[Sean Voisen (:svoisen)]

@Emilio: I know you were looking at focus code recently. Thoughts on this?

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Focus code is technically DOM, so moving there. This is basically https://github.com/w3c/csswg-drafts/issues/2632.

I don't think anybody does that right now, and I tend to think that it doesn't quite make much sense to focus something that doesn't generate a box, but people over there obviously disagree :)

The test-case in comment 0 also seems to imply that display: contents elements are supposed to generate backgrounds and outlines, which is something a bit strange since they don't generate a box to begin with. Outline interop is such a mess that you could hack that up I guess, but seems a bit weird.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 4

[Anne (:annevk)]

Agreed, unless the CSS standard is changed to say that this generates some kind of special box, I think this is WONTFIX (INVALID is hard to argue as lots of focus details are not defined in sufficient detail).

Comment 5

[Mats Palmgren (inactive)]

I don't think that "generates some kind of special box" is necessarily a per-requisite for including an element in keyboard navigation. I'm pretty sure it can be implemented without the element itself having a box.

I think we should wait until there is a clear consensus in #2632 before closing this. (It doesn't look like there is at this present time.)

Comment 6

[François REMY]

I would like to note that setting display:contents on a link is a totally legitimate use case, and because you can't focus those links, the table of contents of w3c spec is about to become keyboard-inaccessible.

see for instance: https://tabatkins.github.io/bikeshed/

This is not an acceptable outcome.

(Regarding the background and outline, I don't have such a strong opinion, I wrote the code to highlight the input in red on focus, then I copy pasted it and changed the colors without thinking about it too much; color would inherit though so the focus on the link would be visible)

Comment 7

[Mats Palmgren (inactive)]

I would like to note that setting display:contents on a link is a totally legitimate use case

Fwiw, I agree with that insofar as "include it in kbd navigation" goes. That seems
consistent with the "display:contents doesn't affect the semantic meaning" part of
the specs. But, I'm fairly strongly against supporting any kind of rendering for
these elements though. That would be against the spirit of what display:contents
is intended to do. If you want some rendering (other than style inheritance) then
you shouldn't use display:contents IMO.

Comment 8

[streltsyn]

I agree with Mats. The elements that would be included in the focus sequence without display:contents should be included there with it. Their descendants should be styleable via selectors like :focus > *, and their ancestors should match the :focus-within pseudo-class. It's OK for them to have no focus styling by default, it's the authors' responsibility to add the distinct focus styles to the visible (and interactive) parts of the subtree of these elements. It's not OK for the authors not to be able to do it.