- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 29 Apr 2026 16:38:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Inheritance makes shadow roots observable`. <details><summary>The full IRC log of that discussion</summary> <kbabbitt> emilio: this came up a couple times ebcause we don't have ... things like select object and a couple others media as well<br> <kbabbitt> ... are elements that in some implementations use shadow DOM to implement their behavior<br> <kbabbitt> ... but it has some implications with inheritance<br> <kbabbitt> ... where inheritance works as, if you slot the contents, if you do something like inherited and noninherited properties might get different values than you expect if you don' tuse shadow dom<br> <kbabbitt> ... this has bit us a couple ties, maybe we need to explicitly define which elements use shadow DOM<br> <kbabbitt> ... option and select in Gecko<br> <kbabbitt> .. do people have strong opinions on this? or should we just define specific shadow trees for this<br> <kbabbitt> astearns: I thought one reason to allow but not require UAs to use shadow DOM was that we wanted that wiggle room across various implementations<br> <kbabbitt> emilio: generally yes but that's been less and less the case with appearance:base<br> <kbabbitt> ... we need to define, ideally it shouldn't affect inheritance behavior, falls out of shadow DOM definition<br> <kbabbitt> ... works across flat tree instead of regular DOM tree<br> <kbabbitt> ... different option would be something like explicit inheritance works through DOM tree, but thats weird and you have 2 styles to inherit from<br> <kbabbitt> ... a number of options discussed in HTML issue that annevk linked<br> <kbabbitt> ... don't think we need a resolution here, unless we feel strongly we don't want to change behavior of shaodw DOM and this should be sorted out in HTML<br> <kbabbitt> ... HTML should define behaviuor of shadow trees<br> <kbabbitt> ... just wanted to get some eyes on it, take a look at some different options<br> <kbabbitt> ... people working on appearance:base and form controls, would be useful to explicitly define how these work<br> <kbabbitt> astearns: one option is to just exhaustively define the shadow trees so that there isn't a difference in observable behavior<br> <kbabbitt> ... which sounds like a lot of work, may not be feasible<br> <keithamus> q+<br> <kbabbitt> astearns: second option I heard was we could change our inheritance behavior in some way<br> <lwarlow> q+<br> <kbabbitt> ... that sounded also like a nonstarter for backcompat reasons, right?<br> <kbabbitt> emilio: not necessarily, we can change it, especially if we define this for UA shadow roots at least<br> <astearns> ack fantasai<br> <kbabbitt> ... would be a nonstarter for changing all shadow DOM, but could say UAs are not allowed to expose shadow roots via inheritance<br> <kbabbitt> ... inherit keyword would need ot be friendly for shadow roots<br> <kbabbitt> ... for option 1, may not be as painful as it seems, only matters for elements that have children<br> <kbabbitt> ... video, object, selecty<br> <kbabbitt> ... children that would be slotted somewhere<br> <kbabbitt> s/selecty/select/<br> <kbabbitt> astearns: are there other options discussed in WHATWG issue?<br> <kbabbitt> emilio: main one was about chaning how inherit works<br> <kbabbitt> ... could also change explicit vs non-explicit inheritance but that might be weirder<br> <kbabbitt> ... affects regular shadow roots to some extent but I don't think that's changeable at this point<br> <astearns> ack keithamus<br> <kbabbitt> keithamus: don't think it's that big a lift to define these shadow roots, there aren;t hundreds of them<br> <kbabbitt> ... we don't have to do at once, mostlyu observable with children and there's maybe 3 of those<br> <kbabbitt> ... could have some definition of a well specified UA shadow root<br> <kbabbitt> ... that allows for precise inheritance rules that are well defined \<br> <kbabbitt> ... elss specified an dundefined ones<br> <astearns> ack lwarlow<br> <kbabbitt> lwarlow: I don't know that we've identified them in all cases<br> <kbabbitt> ... HTML very strongly makes these UA defined in all implementations<br> <kbabbitt> ... different browsers almost definitely have different shadow roots in ways that can';t be changed<br> <kbabbitt> s/identified/defined/<br> <keithamus> q+<br> <kbabbitt> ... maybe it's okay if we want to change them but<br> <emilio> q+<br> <kbabbitt> ... just ones which allow children but others such as input would just be observable if you did weird stuff with DOM APIs<br> <kbabbitt> ... we're going to define shadow trees for input for appearance:base but that doesn't help with appearance:auto<br> <kbabbitt> ... meter, progress can't have children currenlty<br> <kbabbitt> ... I imagine the way the web is, UAs could have shadow roots that aren't the same<br> <astearns> ack keithamus<br> <kbabbitt> keithamus: don't think that's substantially different<br> <kbabbitt> ... details is a slot with summary and a slot with content<br> <kbabbitt> .;.. we don't need to express everything about those<br> <kbabbitt> ... we don't have to specify exact HTML structure, just that it can be composed at these 3 elements<br> <kbabbitt> ... just enough detail to supply correct information for this issue around inheritance<br> <kbabbitt> ... doesn't necessitate enumerating entire HTML in every instance, just observable bits<br> <kbabbitt> ... style tag in closed UA shadow root, no need to specify whether that's allowed because not web observable<br> <kbabbitt> lwarlow: would something like, meter or color input in Firefox with one less level of nesting, might be observable<br> <astearns> ack emilio<br> <kbabbitt> emilio: for things that cannot have children, as long as you don't have a slot, this is not observable. observable that there's a shadow tree because element would start or stop being in flat tree<br> <kbabbitt> ... if you say this element has a shadow tree with no slots, then the specifics are not observable<br> <kbabbitt> ... element outside of flat tree shouldn't e3xpose its style<br> <kbabbitt> ... for this you don't need to define the complete shadow tree, just parts of shadow tree with ? slots<br> <kbabbitt> lwarlow: seems more palatable to me<br> <kbabbitt> ... still problems with stuff like video<br> <kbabbitt> emilio: for those you need to define that they have a slot<br> <kbabbitt> ... styles of slots<br> <kbabbitt> ... maybe say there's a slot with display:none for example and that would be enough<br> <kbabbitt> ... or define that there are no slots<br> <lwarlow> I think this could work then<br> <kbabbitt> astearns: is this something we should take up in form controls task force?<br> <kbabbitt> ... to get a few other WHATWG folks to be part of the discussion<br> <kbabbitt> lwarlow: or in WHATNOT itself<br> <kbabbitt> ... Apple's input on this would be useful, they generally have strong opinoins on shadow root stuff<br> <kbabbitt> ... if it's just defining a shadow root exists and a slot exists, that seems doable<br> <kbabbitt> ... we have task force tomorrow, can bring it up there<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-4345665182 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 April 2026 16:38:23 UTC