Re: [csswg-drafts] [css-contain] CQ vs shadow boundaries (#5984)

The spec is indeed as intended right now, and I think it's best to keep it as it is.

As a general rule, CSS features interact with Shadow DOM by allowing the shadow to hide its details as much as possible. This is an intentional part of the design of Shadow DOM; it's intended to be a tool to allow third-party components to be safely used in a page without everyone having to explicitly avoid collisions. This principle guided the development of how @font-face and similar rules are resolved against references to them; how the ::part() pseudo-element works; etc.

The only two big exceptions to this "shadow DOM doesn't expose internal details" principle are layout and inheritance. Layout is pretty much *intrinsically* required to use the flat tree by its very nature, so it does expose whether a slotted element will, say, become a flex item or grid item. Most of the time this doesn't matter very much, tho, as the most important part of a slotted element's layout is its own 'display' value, which it has control of. 

Plain inheritance works over the flat tree, because that's the least likely to break things - for example, if a component is using a particular text and bg color for itself, having slotted elements inherit the text color makes it likely that they'll maintain proper contrast; if they instead inherited their text color from the host element, it would be very easy to have the text become unreadable (for example, if the outer page was using a dark-on-light theme, but the component was styled in a light-on-dark theme).

CQs don't hit these exceptional cases; they're much more similar to @font-face rules. Whether or not a shadow uses a CQ in it shouldn't be exposed to the outer page; if we do expose it, then it becomes part of the component's implied API contract and can't be changed easily. We don't want it to be easy for pages to break when they update a library providing some components.

> It does seem to me, from examples like this, that our initial resolution might make sense when thinking of shadow DOM as a 3rd-party widget full of unknowns. But these days, many teams are using custom elements with shadow DOM as the basis for an entire component system – and this resolution makes it impossible for e.g. a card component to query the container in its wrapping layout component. And ::slotted() isn't much help, because it forces the containing element to understand and apply styles to any elements that get put inside – resulting in a tight coupling of components.
>
> While the initial resolution makes some sense to me, it basically removes the ability for authors to use container queries well, if they are also using shadow DOM slots for their components. I don't think that's a viable tradeoff.

Yes, Shadow DOM can be used in two pretty different ways. If it's purely an organizational tool for first-party content, the restrictions that shadow DOM imposes can be pretty limiting.

However, this is *absolutely* not something that should be adjudicated on a case-by-case basis. Having a "more open" shadow tree is definitely a useful ability, but it should be done at a base level, so that it affects *all* such features at the same time. I am *strongly* against changing CQs to see into shadow trees on an individual basis, as it would make the platform less coherent and more confusing.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5984#issuecomment-1059602923 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 4 March 2022 23:28:52 UTC