Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"being rendered" interaction with display:contents #1837

Open
zcorpan opened this issue Sep 29, 2016 · 8 comments

Comments

5 participants
@zcorpan
Copy link
Member

commented Sep 29, 2016

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

This comment has been minimized.

Copy link
Member Author

commented May 16, 2017

@lilles

This comment has been minimized.

Copy link

commented May 4, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Nov 18, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 17, 2019

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

This comment has been minimized.

Copy link
Member

commented May 17, 2019

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

This comment has been minimized.

Copy link
Member

commented May 17, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 24, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 26, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.