- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Jan 2023 18:03:23 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Custom properties on :root`.
<details><summary>The full IRC log of that discussion</summary>
<emeyer> Topic: Custom properties on :root<br>
<emeyer> github: https://github.com/w3c/csswg-drafts/issues/6641<br>
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/6641#issuecomment-1367600040<br>
<emeyer> TabAtkins: Authors often define a big set of custom properties on the root element<br>
<emeyer> …These reasonably might want to be used in highlight pseudos<br>
<emeyer> …Currently, highlight pseudos don]t inherit from the normal DOM tree<br>
<emeyer> …So they won’t see any of the stuff on the root<br>
<emeyer> …The way around that is to have that big block have a selector of `:root, ::highlight`<br>
<emeyer> …It’s a little weird and funky<br>
<emeyer> …There are a few suggestions to address this<br>
<emeyer> …One is to have some kind of at-rule allowing you to apply custom properties at a level higher than the root, which highlight pseudos could see<br>
<emeyer> …Another is to change things so that highlight pseudos resolve their vars against the originating element<br>
<emeyer> …Another is to say highlight inherits all custom properties from the root<br>
<miriam> q+<br>
<bramus> q+<br>
<fantasai> ... and maybe all properties from the root<br>
<emeyer> …I don’t like resolving var() differently<br>
<emeyer> …I think it would complicate or break setting vars directly on highlights<br>
<emeyer> …Inheriting from the root element has possibilies, but could cause cascade problems<br>
<emeyer> …Inheriting just custom properties would be a little weird; it has minimal impact but it’s a new way of doing things that might have implementation problems<br>
<emeyer> …Having a root-superior at-rule is also a new weird way to address this<br>
<bramus> A use-case for inheriting only custom properties is `::backdrop`<br>
<emeyer> …Not really sure how to approach this, but leaving as is where you have to select both root and highlights has some implementor objections over memory cost<br>
<fantasai> bramus, why?<br>
<emeyer> miriam: ::backdrop has a similar problem and it’s caused author problems, and articles are starting to pop up about having to address both<br>
<bramus> Authors want it: https://kilianvalkhof.com/2023/css-html/backdrop-doesnt-inherit-from-anywhere/<br>
<emeyer> …I like ::document or something like that, maybe could also respond to dark and light modes<br>
<emeyer> …I’m not sure a document-selecto toggle could respond, though<br>
<fantasai> bramus, but ::backdrop could just inherit from its originating element like all pseudo-elements, couldn't it? why would you want it to inherit from :root specifically<br>
<Rossen_> ack miriam<br>
<Rossen_> ack bramus<br>
<Rossen_> ack fantasai<br>
<Zakim> fantasai, you wanted to distinguish ::backdrop<br>
<emeyer> bramus: There’s author demand for backdrop inheriting custom props<br>
<emeyer> fantasai: That is a little different, as ::backdrop can inherit from its originating element and we should make it do that<br>
<emeyer> …highlights have to inherit from a tree parallel to the document tree<br>
<bramus> Spec says it doesn’t: https://fullscreen.spec.whatwg.org/#::backdrop-pseudo-element<br>
<bramus> “It does not inherit from any element and is not inherited from.”<br>
<emeyer> …I can see reasons why we might want an @document<br>
<TabAtkins> Right, spec says it doesn't, but we can't see any reason *why* it shouldn't inherit.<br>
<bramus> True :)<br>
<argyle> q+<br>
<fremy> +1 to inherit custom properties from :root, I think they are de-facto considered "global" by authors<br>
<emeyer> …Downside to inherit-from-root is that you can only ever get variables from the root, not from other elements between root and the highlight<br>
<TabAtkins> We asked about it in the repo but haven't gotten a response<br>
<Rossen_> ack argyle<br>
<emeyer> argyle: If I do define a bunch of vars on @document I could toggle them, but it’s a good place to put them<br>
<fremy> q+<br>
<emeyer> …The at rule would be the place things are originally defined, but can be changed later<br>
<emeyer> fremy: I don’t see why a document is different form an initial value in this case<br>
<dbaron> argyle, what about miriam's point about things like light/dark mode depending both on media queries *and* an attribute on the root that comes from a user-facing toggle<br>
<emeyer> …Why would we ask authors define things in @document and then ask them to redefine later<br>
<argyle> dbaron:<br>
<emeyer> Rossen_: Any other thoughts?<br>
<Rossen_> ack fremy<br>
<emeyer> (silence)<br>
<emeyer> Rossen_: Do we feel like we’re close to resolution, or should we just capture this and pick it up next week?<br>
<fremy> fremy: (for the minutes, I mentioned how developers already assume :root variables are global, and we could acknowledge them as-is)<br>
<argyle> dbaron: @document { --brand: hotpink }, and for dark mode `@media (prefers-color-scheme: dark) { :root { --brand: deeppink } } .dark { --brand: deeppink }` is what i was thinkin<br>
<emeyer> fantasai: Is there any reason we should NOT have the highlight pseudo inherit from :root?<br>
<emeyer> TabAtkins: If you put color: black on root and then inherit into the highlight, it would break the cascade<br>
<emeyer> fantasai: I think that can work by having the highlight tree break inheritance<br>
<emeyer> …You can have paired default highlight colors happen based on author style rules<br>
<dbaron> s/highlight tree/UA style sheet/<br>
<dbaron> s/inheritance/inheritance for color/<br>
<fremy> @ argyle what is the value of @document here? @property { initial } feels indentical (and, I believe, not that great in this case, you would want the deeppink in dark mode)<br>
<TabAtkins> (I'm completely confused as to what fantasai is trying to say.)<br>
<fantasai> s/highlight tree break inheritance/the UA stylesheet break inheritance/<br>
<TabAtkins> (Either I, her, or both of us dont' understand what we're talking about.)<br>
<emeyer> dbaron: A reason not to add it is that it still doesn’t solve the variables problem when they’re set on something other that the root<br>
<emeyer> Rossen_: We’ll have to close here, the clock has run out<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6641#issuecomment-1404021071 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 January 2023 18:03:25 UTC