[css-contain-3] Should not cq units be interpreted in the flatDom context?

[orstavik]

It looks like the cqw value is interpreted within the logical Dom context, and not the flatDom context. And this behavior seems to differ from the behavior of at least two other relative css units: % and em. Here is a test that illustrate the issue (only a single line of code is different in the last three tests):

https://jsfiddle.net/fcx7rv2a/ (uses cqw directly)
https://jsfiddle.net/0hfnpumq/1/
https://jsfiddle.net/0hfnpumq/2/
https://jsfiddle.net/0hfnpumq/3/

Have I misunderstood something here? Or is this expected behavior?

[orstavik]

The relevant section in the spec is §6. The spec now says:
The query container for each axis is the nearest ancestor container that accepts container size queries on that axis.

The issue is: what is the algorithm for "nearest ancestor"? Now in Chrome, the nearest ancestor container is interpreted as being the nearest container that is also in the same document as the element the cqw unit is applied to. But should it not simply be "the nearest ancestor container in the flatDom", same as % and em?

This other test illustrates that the cqw unit is still interpreted in this document context even when it is wrapped in a css variable.
https://jsfiddle.net/xq3kjs4f/1/

Does this mean that it is impossible to access the cqw unit established in a shadowDom from the lightDom context when slotting an element?

[orstavik]

Example use-case:

1. We have a web component a generic carousel (or card or whatever).
2. This web comp "container" changes the width of the different slot elements (slotting contexts) depending on the available width of the host element. This happens both fluently and abruptly, as the container-query examples show, most likely using container-queries. So far, so good. So far we have used container-queries to style the shadowDom elements, and so far that is all we need.
3. But then we are going to slot elements with text and image content into the web component carousel. At this point, we start to see that we need to adapt for example the font-size of text and the border of the images to both:
   1. the element being slotted (for example a <div> element with too much text needs a smaller font size and important image needs a bigger border in red) and
   2. the size/available space of the slot into which these elements are placed (slotting context).
4. Here we would also like to use cqw and cq units. On the elements in the lightDom that we slot into the web component, we would like to specify the default font size to 10cqw and image border size to 1cqw, and then we would like to adjust the font size to 8cqw for elements with too much text and 3cqw for important images.

[emilio]

This was decided in #5984. cc @mirisuzanne @lilles

[emilio]

FWIW I think flat tree is a more natural choice, generally...

[orstavik]

@philkunz gives a good description of the ownership role the shadowDom/web component has when establishing a "slotting context". And we should extend it:

• the slotting context has always provided/overridden css variables to slotted elements (up to the lightDom).
• the slotting context determine the value of normal relative length units such as % and em for slotted elements (up to the lightDom).

At the top of my head I can think of only one CSS value (in addition to cqw et.al.) that is interpreted against the document only context: css animation names.

On the other side, CSS selectors are interpreted against the document only context. Only a few, clearly marked CSS selectors such as :host, ::slotted(), and ::part() are interpreted against the flatDom.

In my head, this produce the following CSS x document/flatDom model.

@query {                 /*interpreted against the document/lightDom*/
  selector {               /*interpreted against the document/lightDom*/
    property: value;   /*interpreted against the flatDom/shadowDom wins*/
  }
}

If this is the conceptual model, then that would mean that container queries should be interpreted within the document/lightDom context. As with animations. While the container query units such as cqw should be interpreted against the flatDom, as % and --var.

I don't know. Maybe it is possible to wrap all the things you need to slot in a <something> in the lightDom, then slap container-type: inline-size onto that something, and then put the elements you plan to slot into that <something> and then you can use cqw on your slotted elements. A lightDom <slot> mirror of sorts. Or, maybe the better choice is to add a ResizeObserver to all the <slot> elements inside the shadowRoot whose cqw you need to expose to the slotted elements (lightDom) and then make those resizeObserver produce a --cqw variable reflecting the width of the <slot> element. And then go to town with calc(var(--cqw) * 42). It feels like.

[mirisuzanne]

I agree that this is how container queries & units should work. I think it was @tabatkins making the strong argument against querying shadow containers. The argument tho, is that selecting a container is similar to selecting an element, and should be interpreted against the light dom.

[mirisuzanne]

Not sure why I removed agenda+ the first time - maybe waiting for more discussion here. But I think this is worth coming back to.

[lilles]

Selecting a different container for cq units than for the querying container does not make sense, right?

Then, if this needs to be revisited, wouldn't it be better to re-open issue #5984 ?

[emilio]

Yes, I agree with @lilles the container query and container units should use the same mechanism. I still think that the natural choice for that would be the flat tree tho...

[css-meeting-bot]

The CSS Working Group just discussed [css-contain-3] Should not cq units be interpreted in the flatDom context?, and agreed to the following:

• RESOLVED: Close the issue in favor of consistency and reopen #5984.

The full IRC log of that discussion

<emilio> q+
<Frances> Tab: cqw units should be interpreted instead in the like tree rather than the flat tree. cqw units have to be consistent with other container queries in the flatDOM instead of in the normalDOM/
<astearns> ack emilio
<miriam> q+
<Frances> Emilio: Do queries differentiate?
<Frances> Tab: Yes, they do.
<Frances> Emilio: Might not be what you want.
<astearns> ack miriam
<Frances> Tab: Could reopen issue.
<Frances> Miriam: Has a strong argument, to reopen. It is more like inheritance. Would like to reopen it.
<Frances> Alan: Close the issue saying that we want consistency.
<TabAtkins> +1 to closeing this issue for consistency
<miriam> s/Has a strong argument/Thinks this use-case is a strong argument/
<Frances> PROPOSAL: Close the issue in favor of consistency and reopen #5984.
<Frances> RESOLVED: Close the issue in favor of consistency and reopen #5984.