- From: Alan Stearns via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Mar 2022 16:51:51 +0000
- To: public-css-archive@w3.org
Hand-edited minutes, as the bot dropped before it could post: RESOLVED: No change, work on more general solution to more openness across shadow boundaries <details> <fantasai> Topic: CQ and Shadow Boundaries <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5984 TabAtkins: Miriam added to agenda miriam: Issue is, we resolved awhile back that slotted container queries couldn't see containers in the shadow DOM miriam: which from the perspective of saying that Shadow DOM things should be hidden makes a lot of sense miriam: Problem is very common use case with web components and shadow DOM these days is to build an entire design system out of them miriam: you end up with lots of things nested in slots miriam: and if container queries can't respond, feels limiting miriam: decent workaround, similar to can't measure grid track with CQ, add an extra element in the slot and measure that miriam: but wanted to bring that back because feels broken to ppl using the use case miriam: Proposed path forward is that Container Queries can respond to containers that are in the shadow DOM miriam: that does expose a bit about what's in the shadow DOM miriam: but feels similar to exposing inheritance miriam: we're trying to measure space available, and that's impacted by what's in the shadow DOM miriam: I can also seem Tab's perspective, there's a disconnect here in the various ways shadow DOM is used TabAtkins: My position is that containers declared inside a shadow shouldn't be visible to light DOm chilidren distributed in slots TabAtkins: Shadow DOM was designed to be encapsualted as much as possible TabAtkins: some purposeful leaks, e.g. ::parts TabAtkins: and inheritance leaks through the boundaries, but is minor TabAtkins: but a number of other things we didn't want things to leak TabAtkins: e.e.g font-faces in shadow can't be used by light DOM TabAtkins: ... TabAtkins: if you ever say anything in your styles about that font, won't see that font TabAtkins: because loaded in Shadow only TabAtkins: this feels similar TabAtkins: container in the shadow is not necessarily part of the public contract of the shadow implementation TabAtkins: might be internal, not to be exposed TabAtkins: if exposed, then existance of that container *is* exposed TabAtkins: and becomes part of your contract TabAtkins: That said, I can see the useful ness of having containers in your shadow, and making that part of your "API" with surrounding content TabAtkins: This is showing a conflict between shadow DOM as hidden ?? and shadow DOM as organizing mechanism TabAtkins: ... TabAtkins: allows cooperating first-party components TabAtkins: I think we should have a more open shadow DOM that doesn't have info-hiding, and those could expose things like containers and name-defining @rules TabAtkins: but I don't think that should be an exception to shadow DOM as we have it today TabAtkins: we should continue to info-hide when possible TabAtkins: doing this would make it impossible for any UA shadow DOM usage to use containers TabAtkins: and that's problematic TabAtkins: so I thin we should keep spec as is, not exposed miriam: Container in Shadow DOM does impact layout, so that's why it feels weird for it to not impact the measurement miriam: but I do like the idea of having some explicit control here TabAtkins: I do get it. Not a good answer right now. TabAtkins: My preferred decision isn't ideal, it's best given the current tack. TabAtkins: and we should solve the problem more generally Rossen_: My current personal lean is more towards trying to find more general solution, that will work for this and others Rossen_: and not rush into open more dependencies and make shadow DOM less shadowy <emilio> +1 Rossen_: recognizing the pain as well Rossen_: Are we in a position to break that tie? Rossen_: Miriam, how do we feel about this? miriam: As long as we all feel the pain, and want to work towards a general solution Rossen_: Miriam, if we resolve to work on more general solution, would it be objectionable? miriam: No, I would want to work on the more general solution, and teach the workaround for now Rossen_: sounds like consensus to me, anyone else with a different opinion? Rossen_: OK, proposed solution is to leave spec as-is and work on a more generalized solution to less shadowy shadow boundaries Rossen_: any objections? <fantasai> RESOLVED: No change, work on more general solution to more openness across shadow boundaries </details> -- GitHub Notification of comment by astearns Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5984#issuecomment-1083382831 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 March 2022 16:52:23 UTC