- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Mar 2022 17:09:42 +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>
<emilio> topic: custom properties on :root<br>
<emilio> github: https://github.com/w3c/csswg-drafts/issues/6641<br>
<emilio> delan: there's a lot of content out there where a bunch of custom properties are specified on the :root<br>
<emilio> ... historically that's been fine for highlight pseudos because they inherited from the element<br>
<emilio> ... as spec'd now each highlight pseudo has a separate inheritance tree so it'll break that pattern<br>
<emilio> ... so there's a compat issue in that but I don't think that's a huge issue because we've determined that some breakage is acceptable for these highlight pseudo<br>
<emilio> ... but there's two complications for this, one is that authors at least they'd have to switch their stylesheets to `:root, :root::selection, ...` etc<br>
<TabAtkins> :root, :root::selection, :root::highlight, ... { /* set up all the custom props here */ }<br>
<emilio> ... it's also a bit of a perf issue because we might end up with a bunch of property blobs<br>
<emilio> ... there's another option which is using `@property` with an initial value<br>
<emilio> ... it's a lot more verbose and it should work<br>
<TabAtkins> q+<br>
<emilio> ... I guess question is "is that good enough"? Or can we simplify it somehow for authors?<br>
<Rossen_> ack fantasai<br>
<emilio> fantasai: Wondering about two things we could possibly do. One of them is making highlights inherit from the root by default<br>
<emilio> ... which might be a reasonable thing to do?<br>
<emilio> ... or specifying that variables are special and they inherit from the originating element<br>
<fantasai> probably can't inherit from :root for all properties, but for variables might be OK<br>
<emilio> delan: I think the first idea seems cleaner<br>
<emilio> ... I worry if there are any unintended side-effects<br>
<emilio> q+<br>
<emilio> fantasai: I think the idea is "if you're on the root selection" the variable properties would inherit from the root to `:root::selection`<br>
<emilio> ... I wonder if we want to make this work for every element<br>
<Rossen_> ack TabAtkins<br>
<fantasai> TabAtkins: inheriting from originating element appeals, but assuming we want to inherit from a single place could address a larger concern<br>
<emilio> TabAtkins: Inherit from originating element is appealing but if that doesn't happen this could be an opportunity to address a larger concern<br>
<fantasai> TabAtkins: ....<br>
<fantasai> TabAtkins: Argument for root, animations can play into that don't want to play into other places in the tree<br>
<fantasai> scribenick: fantasai<br>
<fantasai> TabAtkins: Few other suggestions, but if we are going to inherit all the highlights from a single place should do in a way that addresses larger concern<br>
<fantasai> TabAtkins: either use initial value from register Properties<br>
<fantasai> TabAtkins: or .... doesn't have animations apply to it<br>
<fantasai> emilio: Want to point out that ::backdrop has the same issue, ::backdrop doesn't inherit from :root<br>
<TabAtkins> s/..../a more ergonomic way to set initial values that/<br>
<fantasai> emilio: it hasn't come up often, but it hsa come up sometimes<br>
<fantasai> emilio: I would rather avoid inheriting from multiple places, because that's messy<br>
<fantasai> emilio: very special-casy<br>
<TabAtkins> like `@root { /* only custom props here */ }`<br>
<fantasai> emilio: we do something like that for ::first-line, and it's a massive pain. Don't wish that to anyone<br>
<fantasai> Rossen_: where do we go from here?<br>
<fantasai> delan: Agree with emilio in general<br>
<fantasai> delan: I think especially highlight inheritane, but a lot about highlight pseudos, is full of special cases<br>
<fantasai> delan: would prefer to avoid adding more<br>
<fantasai> delan: so maybe it's fine?<br>
<Rossen_> q?<br>
<Rossen_> ack emilio<br>
<emilio> ack emilio<br>
<fantasai> delan: Tab does have an interesting point though, that there's a general problem to be solved. Not sure<br>
<fantasai> Rossen_: I'm a bit lost on where we're going from here. What would you like to see, delan?<br>
<fantasai> delan: Leaving aside the more general issue of how we can use variables in non-element contexts<br>
<fantasai> delan: for the core issue, I think consensus was that the best workaround so far is using custom property registrations with initial values<br>
<emilio> having an `@root` or `@document {}` rule that applies to the whole document makes sense to me fwiw<br>
<fantasai> delan: I guess the question I'm unsure about is do we think that is too annoying and unergonamic? No one had an opinion on that in the thread<br>
<fantasai> delan: do we think that's already too annoying?<br>
<fantasai> Rossen_: for developers?<br>
<fantasai> delan: yeah<br>
<argyle> q+<br>
<emilio> q+<br>
<fantasai> TabAtkins: Lea expresses that she find that's too unergonomic to be worthwhile and would prefer something else here<br>
<Rossen_> ack argyle<br>
<fantasai> argyle: I have lots of experience with custom properties, and it's very tedious to ...<br>
<fantasai> argyle: I have a library called openprops with 350 properties<br>
<TabAtkins> Also I'm not 100% sure off the top of my head how @property interacts with being nested in @media and @supports.<br>
<fantasai> argyle: I'm not going to hand-author 300 @property rules so that they can drop into highlight pseudos<br>
<fantasai> argyle: so some kind of higher level place to find these would be great<br>
<fantasai> argyle: would be annoying to convert all my simple props and waiting for browsers to even support that<br>
<Rossen_> ack emilio<br>
<TabAtkins> (to be fair, both of these require waiting for support. but this is simpler than @property, yeah)<br>
<fantasai> emilio: Mentioned on IRC, but having @document or @root or whatever to apply properties to the initial style makes a lot of sense<br>
<Rossen_> ack fantasai<br>
<emilio> fantasai: one advantage of inheriting from their originating element is that if you need to set variables deeper in the tree you can do that<br>
<emilio> ... and then they'd behave as you expect, you might need to change your ::selection rules a bit<br>
<fantasai> emilio: That was the thing I was thinking about. From an author's perspective, what you want is inheriting from originating element<br>
<TabAtkins> I think we'd define @document in cascade?<br>
<fantasai> emilio: Higher-level thing works for some cases, but might also be more confusing<br>
<fantasai> Tab, but it wouldn't inherit that's the problem<br>
<fantasai> Rossen_: Sounds like we need more discussion, suggest we take it back to the issue<br>
<fantasai> Rossen_: maybe you all can start formalizing the various ideas, would be great<br>
<argyle> 👍🏻<br>
<fantasai> Rossen_: and maybe next time we can be closer to a resolution<br>
<fantasai> delan: sounds good<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-1069356665 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 March 2022 17:09:44 UTC