- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Jul 2023 16:19:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo] Custom properties on :root`, and agreed to the following:
* `RESOLVED: highlight pseudos inherit across the highlight tree, and the root highlight inherits custom props from the root element`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> chenney: problem with highlight pseudos with custom properties<br>
<TabAtkins> chenney: right now you have to double your custom props on the root<br>
<TabAtkins> chenney: i summarized the options on the isse<br>
<astearns> s/chenney/schenny/<br>
<dbaron> s/schenny/schenney/<br>
<TabAtkins> schenney: from our perspective (chromium/igalia) our preferred option is that custom props come thru the highlight inheritance chain, then if you get to the root and still dont have a vaue for the custom prop, look at the root element<br>
<TabAtkins> schenney: we feel that has advantage of all th eproposals<br>
<fantasai> summary of the options -> https://github.com/w3c/csswg-drafts/issues/6641#issuecomment-1404031937<br>
<TabAtkins> schenney: simple inheritance chain, don't do two lookups<br>
<TabAtkins> schenney: it addresses the problem that most people put custom props on the root, so we don't have to change our advice<br>
<Rossen_> q?<br>
<TabAtkins> schenney: only problem is that if custom props are further down the tree we won't discover them<br>
<TabAtkins> schenney: But an author always has the ability to put them in the highlight inheritance chain manually<br>
<emilio> q+<br>
<TabAtkins> schenney: So proposal is to use the selection inheritance chain, and put the root element at the top<br>
<TabAtkins> schenney: that's the last proposal in my summary<br>
<Rossen_> ack eli<br>
<bramus> The summary being https://github.com/w3c/csswg-drafts/issues/6641#issuecomment-1641196754<br>
<Rossen_> ack fantasai<br>
<TabAtkins> fantasai: So that means highlight pseudos are able to be assigned custom props?<br>
<TabAtkins> schenney: yes, they can use existing from the root, or you can define them in the highlight itself<br>
<TabAtkins> fantasai: okay, just need to make that clea rin the spec<br>
<Rossen_> ack emilio<br>
<fantasai> summary of latest proposal -> https://github.com/w3c/csswg-drafts/issues/6641#issuecomment-1641196754<br>
<TabAtkins> emilio: Is there beahvior difference between this and saying custom highlights always inherit custom props from the root?<br>
<TabAtkins> schenney: I think that is the proposal<br>
<TabAtkins> schenney: We're only saying to inherit custom props from the root not all<br>
<TabAtkins> emilio: Okay as an aside i think the highlight inheritance is funky<br>
<TabAtkins> emilio: but generally i think it's weird that custom props work in some places but not others<br>
<delan> q+<br>
<TabAtkins> emilio: you can't see a custom prop defined on non-root elements<br>
<TabAtkins> TabAtkins: unless you spam them in<br>
<schenney> q+<br>
<TabAtkins> emilio: it makes me sad that this is more complicated and doesn't solve ::backdrop either<br>
<TabAtkins> TabAtkins: ::backdrop is pretty different<br>
<TabAtkins> iank_: the current behavior in the spec is breaking sites, fwiw<br>
<TabAtkins> fremy: What is that bheavior?<br>
<TabAtkins> emilio: a highlight pseudo inherits from your parents highlight pseudo, etc. then the root's highlight doesnt inherit from the root, so you have to specify your custom props on both root and highliht root<br>
<TabAtkins> emilio: Current non-spec behavior is that selection pseudos just inherit from the originating element, no inheritance from the highlight tree at all<br>
<TabAtkins> delan: clarification - the proposal is not that highlight styles inherit from the root, but rather that they continue to inherit from parent highlight styles, but at the top the root highlight inherits from the root element<br>
<emilio> q+<br>
<Rossen_> ack delan<br>
<fantasai> delan: So we're only changing what happens at the top<br>
<fremy> q?<br>
<TabAtkins> florian: for custom props only<br>
<TabAtkins> delan: Right. there was an earlier proposal where we considered doing it for all, and it's simpler, but it breaks paired defautls which are a really important compat behavior<br>
<emilio> q-<br>
<Rossen_> ack schenney<br>
<TabAtkins> fantasai: 1) if we want internally to implement as inherit everything from root to root highlight, you can do that and set "all:initial"<br>
<schenney> q+ now I recall<br>
<TabAtkins> fantasai: you'll have to pull out writing-mode/direction as well. but internally you can just inherit everything and reset a bunch<br>
<schenney> q+<br>
<Rossen_> ack fantasai<br>
<TabAtkins> fantasai: for ::backdrop I think it's completely unrelated, there's no weird cascading/inheritance behavior<br>
<TabAtkins> fantasai: we should discuss ::backdrop but separately. i dont understand why we didn't give it inheritance to begin with<br>
<TabAtkins> fantasai: I feel like this is a good proposal.<br>
<fremy> q+<br>
<oriol> q+<br>
<TabAtkins> fantasai: if you're using custom props in your highlight styling you'll have to set that on the highlight itself, but at that point you're already selecting that highlight so it's not bad<br>
<emilio> q+<br>
<Rossen_> ack schenney<br>
<TabAtkins> schenney: I still think that taking a resolution to consider the broader solution of different place to define custom props (the @document idea from earlier) I think is still important, it would solve other cases<br>
<TabAtkins> schenney: But I think our current proposal for now will fix the breakage we currently see<br>
<Rossen_> ack fremy<br>
<TabAtkins> fremy: I think I agree with that, we should fix the local problem<br>
<TabAtkins> fremy: One comment, to me it makes sense to inherit properties from the originating element<br>
<TabAtkins> fremy: but you say it would b echallenging from impl perspective<br>
<TabAtkins> fremy: why?<br>
<delan> q+<br>
<TabAtkins> schenney: It's *doable* but it requires two sets of inheritance passes to amke it work as authors expect<br>
<TabAtkins> schenney: you'd have to look down the highlight inheritance chain, and if you didn't find a custom variable you'd have to go back to the originating element and walk its inheritance chain<br>
<TabAtkins> schenney: weird behavior from an author's perspective too, it grates me as an author<br>
<Rossen_> q?<br>
<TabAtkins> fremy: It is still confusing to me that you can't make a property called --selection-color and change it further down and ahve it work, you have to send it to the highlight itself<br>
<TabAtkins> fremy: But it's not for me to say what's hard to implement<br>
<TabAtkins> fremy: I do think the root will solve 95% of the problems<br>
<TabAtkins> (I strongly disagree, I think two inheritances is much worse than just rooting the highlight tree under the root el)<br>
<Rossen_> ack oriol<br>
<TabAtkins> oriol: In the spec we resolved that ::backdrop now inherits from originating element<br>
<Rossen_> ack emilio<br>
<fantasai> TabAtkins: when I asked Anne about it, he didn't know why it was that way, so we fixed it<br>
<TabAtkins> emilio: the backdrop case is similar in that the root el isn't in its inheritance chain, so if that's fixed it's good<br>
<TabAtkins> emilio: But I stil lthink it'll be confusing for authors that they can't set further down the tree<br>
<TabAtkins> fantasai: given that highlihgts don't inherit *anything else* from their originating element, i don't think it's unreasonble to assume the custom props inherit the same<br>
<Rossen_> q?<br>
<TabAtkins> fremy: some things are inherited...<br>
<schenney> q+<br>
<TabAtkins> emilio: currentcolor<br>
<TabAtkins> fantasai: that's not inheritance<br>
<Rossen_> ack delan<br>
<TabAtkins> delan: I think we're getting sidetracked<br>
<TabAtkins> delan: I was originally queued to say that all the breakage we've seen (and we've had dozens of bug reports) were about custom props on root<br>
<ntim> q+<br>
<TabAtkins> delan: So not a single instance reported of breakage from custom props elsewhere in the tree<br>
<TabAtkins> delan: so for the compat issue this should be enough<br>
<Rossen_> ack schenney<br>
<TabAtkins> schenney: re: things coming from originating element, yes currentcolor<br>
<TabAtkins> schenney: And next issue is about another case where we might take some info, still not a property tho<br>
<TabAtkins> schenney: In *all* cases tho, for properties themselves it comes solely thru the highlight inheritance chain<br>
<Rossen_> ack ntim<br>
<TabAtkins> ntim: I see authors put custom props on shadow roots, I'd expect that to work<br>
<emilio> To clarify, ntim means via `:host`<br>
<astearns> +1 to accommodating :host as well<br>
<TabAtkins> :host::selection should work, right?<br>
<delan> does this proposal change anything around that?<br>
<emilio> Having an editor custom-element doing something like `:host { --selection-color: red }` and use that from highlight pseudos seems reasonable...<br>
<emilio> no<br>
<emilio> q+<br>
<TabAtkins> schenney: So if you put custom props on the shadow root, do you want it to have different values for the highlight than elsewhere on the page?<br>
<Rossen_> ack emilio<br>
<TabAtkins> emilio: It seems reasonable if you ahve an editor custom element to set custom props on :host<br>
<TabAtkins> emilio: this is what I was talking about - it seems weird as an author that setting props on the root works but setting anywhere else doens't work<br>
<ntim> I agree with emilio<br>
<TabAtkins> emilio: I understand you can say :host::highlight but I think people wouldn't do that<br>
<TabAtkins> emilio: they'd think if the root case worked, why wouldn't other cases work<br>
<schenney> q+<br>
<TabAtkins> q+<br>
<TabAtkins> emilio: I understand this fixes the compat issue and there are ways to get the behavior you want, i just think it's not great<br>
<Rossen_> ack schenney<br>
<fremy> @ TabAtkins, I'll minute you<br>
<TabAtkins> schenney: I just think the only option would be to go to dual inheritance<br>
<TabAtkins> schenney: Which is a bad option too<br>
<TabAtkins> schenney: So I'd prefer minimum compat maintanance<br>
<emilio> ack TabAtkins<br>
<iank_> i would prefer no double inheritance<br>
<fremy> TabAtkins: I don't agree that this would be confusing for authors<br>
<fremy> TabAtkins: having one single inheritance tree is usual<br>
<florian> q?<br>
<florian> q+<br>
<fremy> TabAtkins: and I feel it would be even more strange if different properties inherit in different paths<br>
<emilio> q+<br>
<Rossen_> ack florian<br>
<fremy> TabAtkins: I can see people stumbling on this once, of course, but they can look up and fix it with specific code<br>
<TabAtkins> florian: going in the same direction, custo props are someitmes used to polyfill regular properties<br>
<fremy> TabAtkins: so I don't see this being a long term confusion for authors<br>
<TabAtkins> florian: Having them be more similar rather than more different probably is better<br>
<Rossen_> ack emilio<br>
<TabAtkins> emilio: i'm just not convinced authors would understand that highlight style inherits from other highlight pseudos and finally the root<br>
<delan> q+<br>
<Rossen_> ack dbaron<br>
<florian> s/going in the same direction/going in the same direction as Tab/<br>
<TabAtkins> dbaron: I have mixed feelings overall, but think im' reasonably sympathetic to TAb's argument about consistent model<br>
<TabAtkins> dbaron: one of the thins we might require authors to do is write something both for the el and its highlights<br>
<florian> s/, custo props are/., custo props are also<br>
<TabAtkins> dbaron: which might b epainful because ther'es several highlight pseudos<br>
<TabAtkins> dbaron: we might want a pseudo that refers to all the highlights.<br>
<Rossen_> q?<br>
<TabAtkins> dbaron: probably only useful for custom props<br>
<TabAtkins> dbaron: would probably make this less painful for moving custom props around<br>
<Rossen_> ack delan<br>
<TabAtkins> delan: I think that's a good idea<br>
<TabAtkins> delan: i also wanted to say that i'm not convinced that the proposed behavior would be too difficult for authors to understand<br>
<TabAtkins> delan: and that it would be much worse than the legacy behavior where selection inherited from the originating el<br>
<TabAtkins> delan: that model, which most brwosers currently have, also has unintuitive aspects<br>
<TabAtkins> delan: for example, i set a selection color and background color on `p`, then the children don't have those colors. highight inheritance fixes that<br>
<TabAtkins> delan: it is somethig authors could trip on but I think i generally agree with TAb, they'll trip over it once and then move on<br>
<Rossen_> q?<br>
<dbaron> (The example I gave was that authors could style element, element::all-the-higlight-pseudos { --custom-properties: values }.)<br>
<TabAtkins> fremy: could we have an example of how you fix this with custom els?<br>
<emilio> `:host, :host::highlight { --foo: red }<br>
<TabAtkins> TabAtkins: you just need to shift them into the highlight tree as well<br>
<TabAtkins> fremy: okay that's not that bad<br>
<TabAtkins> Rossen_: so can we get to a resolution?<br>
<emilio> Well, without dbaron's proposal you'd need `:host, :host::selection, :host::spelling-error, :host::grammar-error, :host::highlight(<foo>), :host::highlight(bar), ... { --foo: red }`<br>
<fremy> sorry, didn't minute that<br>
<TabAtkins> proposed resolution: highlight pseudos inherit across the highlight tree, and the root highlight inherits custom props from the root element<br>
<TabAtkins> Rossen_: objections?<br>
<TabAtkins> RESOLVED: highlight pseudos inherit across the highlight tree, and the root highlight inherits custom props from the root element<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-1642386369 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 July 2023 16:19:40 UTC