- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Mar 2024 00:53:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[CSS Pseudo] Revisit CSS Custom Properties in highlight pseudos`, and agreed to the following: * `RESOLVED: custom properties don't apply to the highlight pseudos. On highlight pseudos, the var() function takes from the originating element.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> schenney: I filed this base don two things<br> <TabAtkins> schenney: first, one of the ocmments on the bug report when we tried to enable the highlight inheritacne chain<br> <TabAtkins> schenney: someone in a tool was setting ac ustom property on ::selection on every element, expected it to use the custom prop from the element<br> <TabAtkins> schenney: seconds, when I looked at SO about the ::selection pseudo, there was at least one answer that ende dup saying "just use custom props for your selection pseudo"<br> <TabAtkins> schenney: so this appears to already be a big beahvior, custom properties driving selection behavior<br> <TabAtkins> schenney: previous browser behavior, this *was* the correct way to do it - customs would inherit thru the originating element chain<br> <TabAtkins> schenney: So I propose we change the spec to also inherit custom props from originating elements<br> <TabAtkins> schenney: This may be grat for devs, but it poses problems for impl and spec<br> <TabAtkins> schenney: First, at minimum it's a memory hog, you have to copy custom props onto all your selection pseudos.<br> <TabAtkins> schenney: every time the property set changes you have to reallocate a new custom property set for the element<br> <TabAtkins> schenney: second, what do you do when a custom prop is defined in both the highlight inheritance chain *and* the originating element?<br> <TabAtkins> schenney: "correct" answer dpeends on context, hard to spec a reasonable behavior<br> <TabAtkins> schenney: So in hindsight I think we shouldn't make the change. But a lot of webdevs have come in and said we *shoudl* make it.<br> <TabAtkins> schenney: So, is there anything sensible to do about when there's clashing declarations?<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: I think one thing suggested in the thread which is fairly simple is to have "normal" properties inherit thru highlihgt chain, but take custom properties from the originating element<br> <TabAtkins> fantasai: and *only* the originating element<br> <TabAtkins> fantasai: so you can't set custom props on an article::selection and have that visible to a span::selection<br> <schenney> q+<br> <TabAtkins> fantasai: but you can set it on `article` and inherit to the span, and then it'll be visible in span::selection<br> <TabAtkins> fantasai: I don't like an interleaved where it's inherited from two places at once, but I think in this limited case it's okay. The entire set of normal and the entire set of custom each have a single place to inherit from<br> <TabAtkins> schenney: I think that's equivalent to saying custom prop defined on highlights are ignored?<br> <TabAtkins> fantasai: No. We *could* define it that way and it probably woulodn't break much. But we could also still allow highlights set on you to win, and just inherit from the element.<br> <TabAtkins> fantasai: but maybe that causes more problems<br> <Rossen_> ack schenney<br> <TabAtkins> schenney: Right, you'd have to say they apply to the element it's set on but not inherited... that causes issues. Simpler to just not allow it<br> <TabAtkins> fantasai: yeah<br> <TabAtkins> schenney: I think this is probably fine.<br> <TabAtkins> schenney: So do we do this for just ::selection or all the highlight pseudos?<br> <TabAtkins> fantasai: all, i think<br> <TabAtkins> schenney: yeah, for consistency<br> <TabAtkins> fantasai: And the same arguments apply for the other highlights too<br> <TabAtkins> schenney: I think there's not enough usage to really draw conclusions from on the other types yet<br> <TabAtkins> fantasai: Lea mentioned wanting to do syntax highlighting with highlight pseudos<br> <TabAtkins> fantasai: being able to use variables with them would be useful<br> <TabAtkins> schenney: syntax highlighting does seem to be the primary usecase for highlights, especially for perf, agreement<br> <TabAtkins> schenney: so proposed resolution: custom properties are disallowed in highlight pseudo-elements. they inherit from the originating element.<br> <dandclark> q+<br> <fantasai> fantasai: would that work for Lea's use case?<br> <fantasai> TabAtkins: yes, because she sets the theme colors on the originating elmeents<br> <TabAtkins> schenney: i think the only difference practically is if you change the custom prop on the originating element chain, in a way that's out-of-sync with how you change the highlight "pseudo-classes" on the chain<br> <TabAtkins> schenney: that's the only way to get into trouble<br> <TabAtkins> dandclark: i was thrown off by Lea's example, it seems you can make it work with either proposal<br> <TabAtkins> dandclark: I think our main concern was not breaking old code relying on the current browser behavior<br> <TabAtkins> schenney: I think that's right<br> <TabAtkins> schenney: My primary motivation is that people currently do a lot of custom properties on the elements and expect it to be visible to the selection. allowing that really increases the likelihood we can actually ship<br> <TabAtkins> dandclark: we are changing long-standing beahvior by changing the selection behavior at all, what's the bar for us to know if it's shippable?<br> <TabAtkins> dandclark: when we switched to inherit custom props from root we got some reports of real breakage, like form github<br> <TabAtkins> dandclark: It sounds like what i'm hearing is that it's not too bad to just inherit the custom props, perfwise<br> <TabAtkins> schenney: from a perf perspective, as long as we don't allow custom props to actually be set on the highlight itself, then from a code compelxity perspective it works fine<br> <TabAtkins> schenney: in trying to launch highlihgts in chromium, we've run into this issue, and people relying on the fact that they could change the selection for just one type of element and explicitly not ahve it inherited<br> <TabAtkins> schenney: But that second one has been fixed in the msot important sites affected by it, so i think with this change we'll have a good chance of shipping the fixes<br> <Rossen_> ack dandclark<br> <TabAtkins> fantasai: So the proposal is custom props don't apply to highlight pseudos. The var() function takes from the originating element<br> <TabAtkins> vmpstr: clarify on var() - that "takes from originating" is just for the highlight pseudos, not in general, right?<br> <TabAtkins> TabAtkins: yes<br> <TabAtkins> RESOLVED: custom properties don't apply to the highlight pseudos. On highlight pseudos, the var() function takes from the originating 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/9909#issuecomment-1982141005 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 March 2024 00:53:15 UTC