- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Apr 2025 17:30:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo-4] Add a pseudo-element to style all highlight pseudo-elements`, and agreed to the following:
* `RESOLVED: Add * to highlight pseudo`
* `RESOLVED: Specificity of * in highlight pseudo is 0`
<details><summary>The full IRC log of that discussion</summary>
<kbabbitt> schenney: context: the custom highlight api and css styling<br>
<kbabbitt> ... each highlight has an ident and a style in css<br>
<kbabbitt> ... and when you use the JS api to add that highlight ident to a range<br>
<kbabbitt> ... everything in that range gets that style<br>
<kbabbitt> ... this issue was raised in relation to custom props<br>
<kbabbitt> .. subsequent changes made that go away<br>
<kbabbitt> ... but it's sitll that if you want to apply certain props to all custom highlights<br>
<kbabbitt> ... you need to repeat for every identifier in your JS<br>
<kbabbitt> ... proposal is to have a special * identifier in CSS so that you can have ::highlight[*]<br>
<kbabbitt> ... which would supplyu props to all custom highlights in the page<br>
<kbabbitt> ... use case: underline type for all custom highlights but each ident might have a different color<br>
<kbabbitt> ... was specifically raised in the issue<br>
<kbabbitt> ... another use case is if you did in CSS highlight * and give it a bunch of props<br>
<kbabbitt> .. then could register different IDs in JS<br>
<kbabbitt> ... and they would all get highlighting from the * highlight<br>
<kbabbitt> ... that would allow diff idents in JS to represent different ranges<br>
<kbabbitt> ... I think this is totally reasonable, and implemented, and would address some developer pain points<br>
<kbabbitt> ... one question: how exactly we deal with the case where there is both * matching all highlight props and a specific ident with a conflicting property<br>
<kbabbitt> ... how to resolve?<br>
<kbabbitt> ... thoughts?<br>
<TabAtkins> q+<br>
<astearns> ack TabAtkins<br>
<kbabbitt> TabAtkins: for the 2nd quiestion of opposing styles<br>
<kbabbitt> ... what seems bvious to me is to do this at style resolution time<br>
<kbabbitt> ... but that's not how you described it here<br>
<kizu> q+<br>
<kbabbitt> ... spelling highlight would receive highlight spelling style since it's more specific than hoghlight *<br>
<kbabbitt> ... both rules apply to spelling element same as if you had 2 spelling rules with contradictory styles<br>
<kbabbitt> schenney: that's the way I understood it<br>
<kbabbitt> ... bramus put in comments implying what TabAtkins just said<br>
<kbabbitt> ... that would not address the case where * has some props and a specific ident has a different set of props<br>
<kbabbitt> ... first question I had was, as far as specificity, does it apply per peroptery within a highlight?<br>
<kbabbitt> ... or does it apply to entire pseudo?<br>
<kbabbitt> TabAtkins: rule is what has specificity<br>
<kbabbitt> ... props that rule applies cascade using rule's specificity<br>
<kbabbitt> ... multiple rules applyikng the same thing, look at selector, that determins which shared props win<br>
<lea> +1 for `::highlight()` or even `::highlight`. I think ideally all functional pseudos should have parameter-less versions. I would be surprised to see that styling `::spelling-error` though, I'd expect that styles all custom highlights and nothing more<br>
<kbabbitt> schenney: I believe that means we could apply bramus's specificity suggestion<br>
<kbabbitt> ... then at style resolution time it would fall through<br>
<kbabbitt> ... (not what I said in my final comment)<br>
<kbabbitt> TabAtkins: right<br>
<kbabbitt> ... it should be exactly the same as if ::spelling-error { color: red } add div::spelling-error {color:blue}<br>
<lea> q+<br>
<kbabbitt> schenney: OK. bramus's suggestion will address<br>
<astearns> ack dbaron<br>
<ntim> This should just match VT functional pseudos for specificity<br>
<kbabbitt> dbaron: was also going to say that the cascade is the normal way to resolve this<br>
<kbabbitt> ... still 2 choices to do it<br>
<kbabbitt> ... you do have the choice of whether to say the ident inside of highlight contributes to specificity where * doesn't<br>
<kbabbitt> ... could define that in different ways but might be constrained by compat<br>
<kbabbitt> ... sounds like that might have been bramus's proposal<br>
<kbabbitt> schenney: thats fundamentally what bramus was getting at<br>
<kbabbitt> ... to paraphrase: highlight with ident has higher specificity than highlight with *<br>
<kbabbitt> dbaron: that's probably one option, modulo compat constraints<br>
<kbabbitt> ... we could say for example taht the ident inside highlight is equivalent to class or tagname specificity<br>
<kbabbitt> ... assuming they have same other stuff in selector, ident would win over *<br>
<kbabbitt> ... the other option is don't try to differentiate based on specificity<br>
<kbabbitt> ... devs could still make one override another by order<br>
<kbabbitt> ... or something else in selector<br>
<astearns> ack kizu<br>
<kbabbitt> kizu: did we consider making a general version not just a functional highlgyt><br>
<kbabbitt> ... were also considering functional version specifies something more specific<br>
<kbabbitt> ... what if we just drop () and it's just highlight?<br>
<TabAtkins> q+ about specificity<br>
<TabAtkins> sighhhhhh<br>
<TabAtkins> ack about<br>
<TabAtkins> ack specificity<br>
<kbabbitt> schenney: that's a question of syntax we use, we could use that to define custom highlight rules<br>
<lea> +1 (in fact, I proposed this above). I think the implied semantics are slightly different though, so need to ask a Q about that<br>
<TabAtkins> q+ to talk about specificity<br>
<kbabbitt> ... bramus thought the * syntax was good because it aligns with similar types of functions<br>
<kbabbitt> ... in view transitions and scroll marker groups<br>
<kbabbitt> ... would be consistent<br>
<astearns> ack lea<br>
<kbabbitt> lea: question: is this pseudo element intended to style every highlight?<br>
<kbabbitt> ... or including spelling error or just custom highlights?<br>
<kbabbitt> schenney: just custom highlight swhich have this problem due to idents<br>
<kbabbitt> lea: agree with kizu that having a version without () makes sense<br>
<ntim> q+<br>
<kbabbitt> ... it's a pattern we've supported before where we allow no parens in functional pseudoes<br>
<kbabbitt> ... bare highlight pseudo might imply to some that it also affects spelling error<br>
<kbabbitt> ... whereas parens makes it more clear<br>
<kbabbitt> ... as a general design principle, if we have () also good to have a version without<br>
<astearns> ack TabAtkins<br>
<Zakim> TabAtkins, you wanted to talk about specificity<br>
<kbabbitt> TabAtkins: re: specificity I don't think there's any back compat issues<br>
<kbabbitt> ... given that highlights are terminal<br>
<kbabbitt> ... we could set whatever specificity we want<br>
<kbabbitt> ... and it wouldn't affect any existing highlight pseudo<br>
<kbabbitt> ... some amount before pseudo, some for pseudo, that's it<br>
<kbabbitt> ... we could still say highlight with a tag is element equivalent, with a * is * equivalent<br>
<astearns> ack ntim<br>
<dbaron> +1 to tab, I was confusing myself earlier :-)<br>
<kbabbitt> ntim: I think we should aim for consistency with view transitions pseudos<br>
<kbabbitt> ... especially functional once<br>
<kbabbitt> s/once/ones/<br>
<kbabbitt> ... where you have to specify either * or ident<br>
<kbabbitt> ... for specificity it should also be consistent with v-t<br>
<kbabbitt> schenney: I couldn't find anything about v-t * specificity or how it would work<br>
<kbabbitt> ... where * and ident could apply to same<br>
<kbabbitt> TabAtkins: in v-t 1 section ??<br>
<kbabbitt> ... talks about pseudos in general<br>
<emilio> https://drafts.csswg.org/css-view-transitions-1/#named-view-transition-pseudo<br>
<kbabbitt> s/??/3.2.1/<br>
<kbabbitt> schenney: did it talk about *?<br>
<dbaron> or https://www.w3.org/TR/css-view-transitions-1/#named-view-transition-pseudo<br>
<kbabbitt> TabAtkins: [quotes spec]<br>
<kbabbitt> ntim: what I said also implies that I don't think we should add a version without parens<br>
<kbabbitt> ... unless we have one for v-t<br>
<kbabbitt> astearns: I think we're converging on allowing * for highlight pseudo<br>
<kbabbitt> ... that applies no specificty, on v-t model<br>
<kbabbitt> ... objections?<br>
<kbabbitt> RESOLVED: Add * to highlight pseudo<br>
<kbabbitt> astearns: whether we have a version without parens can be a separate issue<br>
<kbabbitt> bramus: should we also resolve that specificity is 0?<br>
<kbabbitt> RESOLVED: Specificity of * in highlight pseudo is 0<br>
<kbabbitt> astearns: we are following the v-t model<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9091#issuecomment-2773255154 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 April 2025 17:30:02 UTC