"being rendered" interaction with display:contents

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

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

@emilio

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?

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

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")?

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.

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".

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.

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.

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

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.

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?

CSSWG now has a resolution that, for accessibility reasons, display:contents elements need an outline rendered around their displayed contents when focused:

RESOLVED: Outline of 'display: contents' is propagated to children for painting (for a11y on focus);

IMO, this clearly implies that display:contents elements must be focusable, and thus should be considered rendered.

Maybe the it would be sufficient to update the definition of "being rendered" like the following?

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

What is "content"?

I tried to find something short for something like "any of the element's inclusive descendants or their CSS generated content pseudo-elements". I agree that it was too vague for the definition.

Allow elements with display:contents to be focused.

Add support for allowing elements with display:contents to be focused.

Bug 1825055 [wpt PR 39247] - Add support for allowing elements with d…

Allow elements with display:contents to be focusable

Bug 1825055 [wpt PR 39247] - Add support for allowing elements with d…

Add support for allowing elements with display:contents to be focused.

Allow elements with display:contents to be focusable

Bug 1825055 [wpt PR 39247] - Add support for allowing elements with d…

Navigation Menu

Repository navigation

"being rendered" interaction with display:contents #1837

19 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

"being rendered" interaction with display:contents #1837

Description

Activity

zcorpan commented on May 16, 2017

lilles commented on May 4, 2018

emilio commented on Nov 18, 2018

SelenIT commented on May 17, 2019

domenic commented on May 17, 2019

domenic commented on May 17, 2019

SelenIT commented on May 24, 2019

emilio commented on May 26, 2019

domenic commented on May 26, 2019

annevk commented on May 27, 2019

SelenIT commented on May 27, 2019

SelenIT commented on Jun 6, 2019

domenic commented on Jun 6, 2019

SelenIT commented on Jun 6, 2019

19 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions