- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jan 2025 21:43:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo] Allow custom Properties in ::selection pseudos (revisited)`, and agreed to the following:
* `RESOLVED: allow custom properties on highlight pseudos`
* `RESOLVED: Allow custom properties on highlight pseudoes; custom properties continue to inherit from the originating element`
<details><summary>The full IRC log of that discussion</summary>
<kbabbitt> schenney: on our 3rd attempt for highlight inheritance in chrome<br>
<kbabbitt> ... TabAtkins and lea pointed out that we want custom props on highlights<br>
<kbabbitt> ... previous resoution was no custom props on highlights, inherit from originating element<br>
<kbabbitt> ... think it's a no brainer we should allow custom props on pseudo highlights<br>
<kbabbitt> ... then there's a question of how we inherit<br>
<kbabbitt> ... 2 possibilities<br>
<kbabbitt> fantasai: let's do in one go<br>
<kbabbitt> schenney: the simplest way to implement is to use existing model for inheritance<br>
<kbabbitt> ... in highlight pseudoes<br>
<kbabbitt> ... inherit through originating element chain<br>
<kbabbitt> ... look first on highlight then on originating element<br>
<kbabbitt> ... which inherits through remaining element cain<br>
<kbabbitt> ... inherit custom properties for highlights through originating element chain<br>
<kbabbitt> fantasai: but not regular propertes<br>
<kbabbitt> schenney: yes<br>
<kbabbitt> ... simple to implement, matches previous behavior<br>
<kbabbitt> ...downside is that custom props have diff inheritance model from every other property allowed on highlights<br>
<kbabbitt> ... alternative method allows inherit both through highlight chain and originating chain<br>
<kbabbitt> ... inherit from highlight chain, and on top of that from originating element<br>
<kbabbitt> ... and then any properties on highlight itself<br>
<kbabbitt> .. downside is hard to state, pain to debug<br>
<kbabbitt> ... not all browser can implement efficiently]<br>
<kbabbitt> ... upside is that it allows authors to put custom props on highlight without knowing they're special<br>
<kbabbitt> ... whereas inherit from origin requires additional explanation<br>
<kbabbitt> ... from that perspective I like the fact we can transition to both methods existing at same time<br>
<kbabbitt> ... but ack that it's messy<br>
<kbabbitt> ... should we go for simplicity but annoyance to developers vs complexity with both methods<br>
<TabAtkins> q+<br>
<astearns> ack fantasai<br>
<kbabbitt> fantasai: say I set color: customcolor<br>
<kbabbitt> ... and then customcolor is set to blue ... on a highlight pseudo<br>
<fantasai> span::selection { color: var(--customcolor); }<br>
<fantasai> p::selection { --customcolor: blue; }<br>
<fantasai> span { --customcolor: red; }<br>
<kbabbitt> fantasai: now the question is what color is the selection/<br>
<kbabbitt> ... from author perspective both red and blue are reasonable<br>
<kbabbitt> ... we've set custom-color close to where we're using it<br>
<kbabbitt> ... we've also set it differently on selection element<br>
<kbabbitt> ... you're proposing a priority between these two, will that make sense to everyone?<br>
<kbabbitt> ... even when there's an ancestor in between?<br>
<kbabbitt> schenney: yes. so...<br>
<kbabbitt> ... people who have been working before the originating element will have priority<br>
<kbabbitt> ... people coiming new, prent will have priority<br>
<kbabbitt> ... agree each is equally valid<br>
<kbabbitt> ... inherit from parent, then originating, then span, so color will be red<br>
<kbabbitt> ... reason for this is it supports back compat use case<br>
<kbabbitt> ... if there's any ambiguity<br>
<kbabbitt> ... you've hit the footgun where it's unclear when we inherit from both<br>
<kbabbitt> ... I'd expet people to use one or other<br>
<fantasai> p::selection { --customcolor: blue; }<br>
<kizu> q+<br>
<kbabbitt> ... if they use both, colors should match up<br>
<fantasai> p { --customcolor: red; }<br>
<kbabbitt> fantasai: in first example [in irc] you'd get red?<br>
<dbaron> (It seems a bit weird if --customcolor inherits differently from color.)<br>
<kbabbitt> schenney: yes<br>
<kbabbitt> fantasai: second example also red?<br>
<kbabbitt> schenney: no blue\<br>
<kbabbitt> [crosstalk]<br>
<kbabbitt> fantasai: no dispute that text not inside span is blue<br>
<kbabbitt> ... part inside span is red or blue?<br>
<kbabbitt> .. because span's value for custom color is read<br>
<kbabbitt> schenney: yes<br>
<kbabbitt> ... it would be read<br>
<kbabbitt> s/read/red/<br>
<kbabbitt> ... originating will override inheritance<br>
<kbabbitt> ... from a back compat perspective we want to inherit from originating element chain and be done<br>
<kbabbitt> ... these questions don't arise which is good<br>
<kbabbitt> ... we'd have to give advice to authors<br>
<kbabbitt> ... custom properties in highlight are distinct from other custom props<br>
<kbabbitt> ... pseudos need to have same values as elements<br>
<kbabbitt> ... andruud is for just inherit through originating element chain<br>
<kbabbitt> ...because it avoids complexity<br>
<kbabbitt> ... which is why I implemented it that way in Chromium<br>
<florian> q+<br>
<kbabbitt> ... purely the feature I'm thinking about<br>
<astearns> ack TabAtkins<br>
<kbabbitt> TabAtkins: with andruud on just use originating element<br>
<florian> q-<br>
<kbabbitt> ... zipper concept you're describing is not possible under current def of inheritance<br>
<kbabbitt> ... a prop always has an inherited value from a particular spot<br>
<kbabbitt> ... we'd have to invent a new concept which is possible<br>
<kbabbitt> ... but sticking with current model is favorable if it can be avoided<br>
<astearns> ack kizu<br>
<kbabbitt> kizu: don't think it will matter in practice<br>
<kbabbitt> ...maybe author will expect things to behave the same<br>
<kbabbitt> ... the way you inhert through highlight elements makes sense since you don't want color to match backgruond<br>
<kbabbitt> ... but I don't think this will matter in practice<br>
<kbabbitt> ... what will be simpler should be okay<br>
<kbabbitt> ... not a point of confusion because not a common use case<br>
<astearns> ack fantasai<br>
<kbabbitt> fantasai: it could make sense to allow a custom prop to be set on highlight and then use directly on same highlight pseudo<br>
<kbabbitt> ... but this double inheritance is weird and will cause problems<br>
<kbabbitt> ... won't match what people expet<br>
<kbabbitt> schenney: that's option 1<br>
<kbabbitt> ...only resolution needed there is allow custom props on highlight pseudos<br>
<kbabbitt> ... which I'm totally fine wityh<br>
<kbabbitt> Proposed: allow custom properties on highlight pseudos<br>
<kbabbitt> RESOLVED: allow custom properties on highlight pseudos<br>
<fantasai> PROPOSED: Allow custom properties on highlight pseudoes; custom properties continue to inherit from the originating element<br>
<fantasai> RESOLVED: Allow custom properties on highlight pseudoes; custom properties continue to inherit 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/11317#issuecomment-2622922904 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 January 2025 21:43:49 UTC