- 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