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 · 25 comments
Open

"being rendered" interaction with display:contents #1837

zcorpan opened this issue Sep 29, 2016 · 25 comments

Comments

@zcorpan
Copy link
Member

@zcorpan zcorpan 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
Copy link
Member Author

@zcorpan zcorpan commented May 16, 2017

@lilles
Copy link
Contributor

@lilles lilles 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
Copy link
Contributor

@emilio emilio 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
Copy link

@SelenIT SelenIT 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
Copy link
Member

@domenic domenic 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
Copy link
Member

@domenic domenic 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
Copy link

@SelenIT SelenIT 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
Copy link
Contributor

@emilio emilio 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.

@domenic
Copy link
Member

@domenic domenic commented May 26, 2019

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
Copy link
Member

@annevk annevk commented May 27, 2019

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
Copy link

@SelenIT SelenIT commented May 27, 2019

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?

@SelenIT
Copy link

@SelenIT SelenIT commented Jun 6, 2019

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.

@domenic
Copy link
Member

@domenic domenic commented Jun 6, 2019

What is "content"?

@SelenIT
Copy link

@SelenIT SelenIT commented Jun 6, 2019

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.

@ExE-Boss
Copy link

@ExE-Boss ExE-Boss commented Jun 6, 2019

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

To me, that seems to imply that display: contents shouldn’t affect it as descendant items still generate layout boxes as normal.

@SelenIT
Copy link

@SelenIT SelenIT commented Jun 7, 2019

It seems that the term "a box associated with the element" is quite ambiguous and still needs some clarification. On the one hand, it can be read as a broader synonym for "a box generated by the element" (that sounds more natural for CSS devs), but applicable to SVG and (largely hypothetical) "other styling languages".

On the other hand, the CSS Display Level 3 actually does use the term associated, but it's not defined normatively, and seems to mean different things in different contexts. E.g. in the phrase

An anonymous box is a box that is not associated with any element

it seems to mean more-or-less the same as "generated by" (otherwise, we would say that an anonymous box is "associated" with the parent element which would generate more than one box in this case). However, later in the Glossary section we have the following definition (emphasis mine):

containing block
A rectangle that forms the basis of sizing and positioning for the boxes associated with it (usually the children of the box that generated it)

which seems to imply that many boxes can be associated with one particular aspect of the element, and the box subtree of the element can be considered somehow associated with the parent element (at least, in some circumstances).

@tabatkins
Copy link
Collaborator

@tabatkins tabatkins commented Jun 9, 2019

"associated" isn't a term of art in that spec, it has its regular English meaning.

(Sorry for the drive-by correction; I'm happy to help provide wording guidance here, but I'm not sure exactly which definition y'all wanna fix.)

@SelenIT
Copy link

@SelenIT SelenIT commented Jun 10, 2019

My idea was to update the "being rendered" definition to treat any element with the non-empty box tree as rendered. This way only elements with display:none (in the CSS terms) would be considered non-rendered, and there will be no "non-rendered elements that the user still can see and interact with" that confuse authors.

@rniwa
Copy link
Collaborator

@rniwa rniwa commented Jun 10, 2019

Sounds like we need a more precise definition of associating a CSS box with an element in CSS?

any element with the non-empty box

That still sounds ambiguous. What does it mean for an element to be with a non-empty box tree?

@SelenIT
Copy link

@SelenIT SelenIT commented Jun 11, 2019

It seems that the HTML spec definition tries to be more general, considering SVG boxes and "some equivalent in other styling languages" along with CSS boxes, so updating the CSS definition would probably be not enough. Changing the HTML definition seems more reliable to me.

My suggestion was to replace the word "element" in the current definition of "being rendered" with a new term/phrase that would include

  • the element itself
  • its descendant elements
  • its descendant text nodes
  • the CSS generated pseudo-elements (e.g. ::before) of the element or its descendant elements...

i.e. anything that is somehow displayed to the user and for what the element in question is an ancestor. With this change, the definition should become unambiguous regardless the exact interpretation of the "box/element association".

@annevk
Copy link
Member

@annevk annevk commented Jun 11, 2019

I don't think HTML's definition needs to be more general and CSS already needs to deal with SVG one way or another. We should strive to simplify that setup, not make it appear more grand than it really is.

@SelenIT
Copy link

@SelenIT SelenIT commented Jun 11, 2019

If it's possible to use CSS as direct reference in the "being rendered" definition, maybe it can be defined like "An element is being rendered if its CSS display is other than none"?

@emilio
Copy link
Contributor

@emilio emilio commented Jun 12, 2019

That doesn't work for descendants of display: none elements.

@SelenIT
Copy link

@SelenIT SelenIT commented Jun 12, 2019

Valid point. Then maybe something like

An element is being rendered if any of its shadow-including inclusive descendants or their CSS pseudo-elements has associated CSS layout boxes, SVG layout boxes, or some equivalent in other styling languages

would work?

@SelenIT
Copy link

@SelenIT SelenIT commented Jan 4, 2021

Are there any objections to redefining "being rendered" as following?

An element is being rendered if any of its shadow-including inclusive descendants or their CSS pseudo-elements has associated CSS layout boxes, SVG layout boxes, or some equivalent in other styling languages

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants