- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 28 May 2026 15:19:57 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Inheritance makes shadow roots observable`, and agreed to the following: * `RESOLVED: emilio will start surveying various places where shadow dom is required and where slots exist and come up with various dispositions of properties` <details><summary>The full IRC log of that discussion</summary> <jarhar> annevk: is it documented in the issue what the observable thing is?<br> <jarhar> emilio: its what you inherit from<br> <jarhar> dbaron: i tried to write a statement in the issue thats what i thought it was, expanding on what emilio wrote<br> <jarhar> dbaron: the last two comments in the issue are attempting to define what the observable thing is<br> <jarhar> dbaron: in the whatwg issue<br> <astearns> associated: https://github.com/whatwg/html/issues/3748<br> <jarhar> annevk: sounds tricky if we have to define the value of each css property<br> <jarhar> emilio: that only comes up if you apply properties to the slot<br> <jarhar> dbaron: inerhited properties inherit and non inherited have initial values, and then you have to specify when thats not the case<br> <jarhar> annevk: slot has display contenets, so that changes display and therefore that ends up showing up<br> <jarhar> emilio: right, if you did display:inherit youd observe a different value based on slotting<br> <jarhar> annevk: maybe it can still be in the rendering sectin, but it cant depend on the appearance value whether it has a shadow tree<br> <jarhar> emilio: i dont think we want to do that<br> <jarhar> emilio: blink and gecko will style the tree differently but it will be the same<br> <jarhar> annevk: we do something similar, but we also have lazy shadow tree creation and i wonder if thats observable with this<br> <jarhar> dbaron: joey could comment on this but blink does some parts of shadow tree are used or not used based on appearance, but the shadow tree is still there<br> <jarhar> annevk: we dont always create the shadow tree when the element is created<br> <jarhar> emilio: the kind of things you can observe via style you need a shadow tree for. if you call getcomputedstyle, in order to get a meaningful value, the element has to be in the flat tree<br> <jarhar> annevk: we defer creating the shadow root until style is needed i think<br> <jarhar> emilio: i dont think thats a concern. you need the shadow tree to be styled<br> <jarhar> emilio: and you need the ancestors to be styled<br> <jarhar> annevk: so we have to define whether it has a shadow tree, whether it has slots, and what the properties are of those slots<br> <jarhar> annevk: and maybe can there be stuff between the root and the slot<br> <jarhar> dbaron: i dont think you have to define can there be stuff between the root of the slot but the overall effect of inheriting properties. it doesnt matter where that effect happens<br> <jarhar> emilio: tldr i think this is a lot more feasible than lets define the whole video shadow tree<br> <jarhar> annevk: yeah we dont want to do that<br> <jarhar> smaug: in what cases are there slots? select has slots<br> <jarhar> annevk: details, option, optgroup<br> <jarhar> emilio: they dont have shadow trees in gecko<br> <jarhar> annevk: you might need that for customizable select<br> <jarhar> emilio: fieldset doesnt<br> <jarhar> astearns: is enumerating all of these really useful here? we should probably come up with a solution where if we need to add shadows and slot in the future<br> <jarhar> emilio: its useful to see if this proposed model breaks down on any existing element, and i think it doesnt<br> <jarhar> emilio: we can probably agree on it<br> <jarhar> annevk: can we agree on who is going to do the work?<br> <jarhar> emilio: i can help with it, sure. idk if i can get to all of it. i can do video input and so on. they can be relatively easily defined. select may be tricky because idk the state of customizable select<br> <jarhar> emilio: i can take on some of these and take it from there and build a list so we know whats left<br> <jarhar> annevk: we should probably continue doing it through statements in the rendering section. rendering is close to style, and it doesnt impact semantics of these elements<br> <jarhar> annevk: we should just make sure that its not dependent on appearance<br> <jarhar> astearns: what is the plan?<br> <jarhar> emilio: effectively emilio goes and builds a list of all the elements and defines a few of them that should be uncontroversial, adds tests, and we can build from there<br> <jarhar> smaug: what does define mean?<br> <jarhar> emilio: define whether theres a shadow tree, is there a slot, what properties apply to it, etc<br> <jarhar> emilio: the main difference is between inheriting from the element and inheriting from the slot, there is a difference which is well defined<br> <jarhar> emilio: if you have object displaly inline and theres a child with display inherit then youd get display contents or display inline<br> <jarhar> emilio: im optimistic that everything here can be defined<br> <jarhar> proposed resolution: emilio will start serving various places where shadow dom is required and where slots exist and come up with various dispositions of properties<br> <jarhar> proposed resolution: emilio will start surveying various places where shadow dom is required and where slots exist and come up with various dispositions of properties<br> <jarhar> RESOLVED: emilio will start surveying various places where shadow dom is required and where slots exist and come up with various dispositions of properties<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3248#issuecomment-4565579232 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 28 May 2026 15:19:57 UTC