[cssom-view] `getClientRects()` should return a flattened list of child rects for `display: contents`

[LeaVerou]

Spec: https://drafts.csswg.org/cssom-view/#dom-element-getclientrects
Testcase: https://codepen.io/leaverou/pen/GgRPVgg

Currently, for display: contents elements, getClientRects() returns no rects, so getBoundingClientRect() returns an empty bounding box. This breaks literally every library or component doing anything related to positioning (e.g. popups, popovers, etc), as they typically rely on getBoundingClientRect(), which in turn is computed as a union of getClientRects(). It even breaks the UA devtools!

This is not just an inconvenience, I think it's also not architecturally sound: for everything else (e.g. flexbox, grid, etc), display: contents basically "offloads" layout to the element's children, so it seems reasonable getClientRects() should do the same and return a flattened list of the rects of its children.

One concern at this point is web compat, but @tabatkins thought because it's limited to display: contents it may be okay.

[schenney-chromium]

From a compat perspective, why would you be relying on this behavior, other than to check for this situation in practice so you can work around it.

[tabatkins]

Agreed that we should fix this, and that compat is unlikely to be a problem.

[RobMayer]

Forgive what must be a naive question, but this - in theory - would allow for, say, an element to position-anchor to something with display: contents and it would utilize the bounding box of that elements collective children as its positional reference, yes?

if so - heck yeah batman!, that'd be awesome. In the last two weeks I've hit about a half dozen scenarios where this would be a blessing.

Edit: I think I might have found the [disappointing] answer - according to specs display: contents still doesn't generate a 'principle box', and therefor wouldn't be a valid 'anchor-box'. Would this still hold true despite this change? and if not, does the underlying intent of changing the return of getBoundingClientRect() venn with how position-anchor ideally ought to work?

[bfgeek]

Would this still hold true despite this change?

It would. display:contents elements are completely transparent to layout, we can't use them for anchor positioning because they don't exist.

[RobMayer]

This might be going out of bounds of scope on this particular topic, and if it is, I'm happy to raise this as a thing elsewhere.

It would. display:contents elements are completely transparent to layout, we can't use them for anchor positioning because they don't exist.

I guess I'm wondering if this ought to be some sort of exception. If one of the reasons behind having display: contents give a non-zero bounding box is to let popover component authors attach their popovers to that element despite it not being part of layout, then I'd posit that we ought to be able to do the same with browser-native popover/anchor.

[LeaVerou]

I agree that we should fix this and that compat is not a problem, I was just mentioning it in case, as some teams are more risk averse than others.

Yes, anchor positioning also working would be great. Not sure if this would be sufficient for it, I suspect it would need a separate exception, but I cannot imagine any cases where the current behavior would be desirable.

As for use cases, the one I’ve run into is web components wrapping natives to get the UA a11y and behavior but wanting to still make them stylable from the outside with regular CSS properties and without parts. Eg a wrapping a native but still wanting properties on the host to work, and style the underlying button. Applying display: contents on the host and inheriting liberally on the shadow button seems to be the only way to do this, not just currently, but in the forseeable future (in some cases even if extending builtins were a possibility).

[Loirooriol]

I don't think I agree with the proposal.

First, an element with display: contents generates no box of its own, so getClientRects() being empty seems reasonable to me.

Then, if getClientRects() redirects to children, it can create a disparity with other APIs. Should ResizeObserver also return/track the list of sizes of the children? clientWidth? Etc.

Also, what children would be reported, exactly?

• Text nodes have no getClientRects(), are they included?
• Pseudo-elements have no getClientRects(), are they included? Which ones?
• Would this choose children in the flat tree? Even if that would expose number of contents of a closed shadow host?
• Should absolutely positioned children be included? I can imagine authors not wanting them since they are out-of-flow

It just seems an inconsistent can of worms to me. I think it's better to defer this to authors if they want to do something special if getComputedStyle(el).display === "contents".