"being rendered" interaction with display:contents

[zcorpan]

display:contents

The element itself does not generate any boxes, but its children and pseudo-elements still generate boxes as normal. For the purposes of box generation and layout, the element must be treated as if it had been replaced with its children and pseudo-elements in the document tree.

https://drafts.csswg.org/css-display/#valdef-display-contents

"being rendered"

An element is being rendered if it has any associated CSS layout boxes, SVG layout boxes, or some equivalent in other styling languages.

https://html.spec.whatwg.org/multipage/rendering.html#being-rendered

So an element that is display:contents is not "being rendered". Check the uses of "being rendered" if that makes sense.

Related: w3c/csswg-drafts#540

[zcorpan]

w3c/csswg-drafts#540 is now resolved as follows:
https://drafts.csswg.org/css-display/#unbox

[lilles]

Stumbled into this one for innerText. There's a wpt relying on "being rendered" being true for display:contents. innerText is spec'ed to return textContent for elements not being rendered.

Gecko considers display:contents to be rendered for textContent. Another reference to "being rendered" in the HTML spec where this matters is https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-fragid:being-rendered

For that case, Gecko does not scroll to a display:contents fragment.

@emilio do you know how consciously this is done in Gecko?

[emilio]

Oh, I somehow missed that mention... But the answer is "Gecko's innerText impl was a bit bogus", see web-platform-tests/wpt#12580.

[SelenIT]

In the CSSWG issue linked above (2362), it turned out that treating elements with display:contents as "not being rendered" conflicts with the general rule and intent that CSS display other than none shouldn't affect the semantics and interactivity of the element. Specifically, it turns off the focusability of the otherwise focusable element (at least, removes it from the tab focus sequence).

I believe that treating an interactive element that has visible subtree and can be activated through it as "not being rendered" is confusing and counter-intuitive. Wouldn't it be better to revisit this definition (or change the focusability criteria from "element has associated CSS boxes" to something like "element or its subtree has any visible/interactive parts")?

[domenic]

Revising the focusability criteria seems reasonable to me, but I'd like to to be as well-defined as possible. Moving from "has CSS boxes" to "has any visible/interactible parts" seems like a step down in rigor.

[domenic]

It's also possible that this problem occurs more than just for focus, in which case the better revision may be to change the definition of "being rendered".

[SelenIT]

I found the usage of the "box tree" term in the spec (in the section about Focusable areas). Maybe it can be reused for "being rendered", like the following?

An element is being rendered if any of the element itself, its descendant nodes, or pseudo-elements associated with the element itself or its descendant nodes, generate a box or text run in the box tree.

[emilio]

Revising the focusability criteria seems reasonable to me, but I'd like to to be as well-defined as possible. Moving from "has CSS boxes" to "has any visible/interactible parts" seems like a step down in rigor.

Yeah, that is true. Also, it seems a bit weird to define that an element with display: contents is focusable, fwiw. While I get the sentiment, per definition elements with display: contents generate no boxes, which means that they generate no overflow, no background, no outlines...

I wouldn't know how to implement a "focusable display: contents element", except hacking up the whole layout engine to display some kind of outline on descendants that contributed to some overflow area? Which overflow area should that contribute to, I don't know... Descendants of display: contents elements can be all over the layout tree.

[domenic]

Although at first glance I am sympathetic, it seems that debate has already been had at w3c/csswg-drafts#2632, and the conclusion is that they should be focusable, even if you don't draw any outline around them.

In other words, break it down into observable consequences:

• document.activeElement will change
• It affects sequential focus navigation (although there are a lot of UA-defined steps there, so the UA could also just leave it out)
• :focus will match
• People or UAs can try to style :focus, but maybe they'll put something like a background or border or outline which doesn't work on display: contents, and if so, that's fine

[annevk]

Does w3c/csswg-drafts#2632 (comment) match implementations though? If browsers use the box tree and there's no box tree, many of these things will be affected unless they are somehow specifically catered for (likely by creating some special box), so I'm not sure the conclusion there is fully accurate.

[SelenIT]

The exact problem is that there is a box tree in case of display:contents (totally unlike the display:none case!). It only misses just one box (the box for element itself), but all other boxes in it remain fully visible and interactive (they can be clicked and this activates the element through event bubbling). However, the definition of "being rendered" and related concept of focusability are currently tied to this one box, not the presense/visibility of the box tree, and this discrepancy currently leads to behavior which is counterintuitive for both authors and users. So maybe there are better options for this case than to tie focusability etc. to that one box?