Repository navigation
[css-pseudo] highlight pseudos and custom properties #6264
Description
https://drafts.csswg.org/css-pseudo-4/#highlight-styling
[ISSUE 1] Are there any other properties that should be included here?
Should custom properties be allowed on highlight pseudos? What about use of cascading variables? If so, does the rule stating that non-inherited properties are to be treated as inherited, apply to registered custom properties where inherit = false?
I suppose these features are ok, given that we’ve completely isolated highlight inheritance from originating element inheritance. As a result, defining or changing a custom property value should already be unable to “escape” and affect layout.
Activity
delan commentedon May 19, 2021
(ping @frivoal, or maybe @fantasai?)
tabatkins commentedon May 20, 2021
Ah yeah, custom properties should be allowed. Hm, we should make sure the same applies to other non-tree-abiding pseudos; custom properties should always be available.
(
var()is always allowed; that's not restrictable. It just needs custom properties to be allowed to be meaningful. ^_^)Good question. Hm. I suspect yes, they should have the same fallback inheritance, for the same reason we fallback-inherit the existing properties. I wouldn't be broken-hearted if we decided the other way for impl reasons, but I'd prefer giving them the same behavior.
(Just to be clear for people, like me, who weren't aware of this rule: properties like 'background' don't inherit normally, but if nothing else defines them, they'll try to inherit from the parent highlight of the same type, so you can set 'background' on a block's highlight and the highlights within it will work as expected. This way you don't have to predict exactly what element to set things on.)
delan commentedon Jun 15, 2021
Thanks @tabatkins! I think I’ll try to implement this in Chromium, then come back and add this to the agenda.
For now it looks like we need two spec changes: #highlight-styling should include custom properties in its list, and #highlight-cascade should clarify that the “regardless” rule applies even to registered custom properties where the inherit flag is false.
LeaVerou commentedon Jun 29, 2021
Are there any pseudos in which custom properties should not be allowed? If not, can we enable them on all of them in one fell swoop so we don't need to explicitly enable them for every pseudo-element?
delan commentedon Jun 29, 2021
I’m not aware of any, for what it’s worth, but maybe some of the other members can say for sure.
Loirooriol commentedon Jun 29, 2021
And also to tree-abiding ones like ::marker. They aren't listed in https://drafts.csswg.org/css-lists/#marker-properties
css-meeting-bot commentedon Jun 30, 2021
The CSS Working Group just discussed
highlight pseudos and custom props, and agreed to the following:RESOLVED: Add custom properties support to psudo elementsThe full IRC log of that discussion
<TabAtkins> Topic: highlight pseudos and custom props<TabAtkins> github: https://github.com//issues/6264
<bkardell_> ScribeNick: bkardell_
<bkardell_> TabAtkins: A chromium implementer was asking if custom properties should work on highlight pseudos and should have the same details -- lea was asking if there were any pseudos they shouldn't work on
<bkardell_> TabAtkins: we should probably make a blanket statement that they are valid on all pseudo elements
<bkardell_> Rossen_: opinions?
<bkardell_> leaverou_: the only pseudos I could think of where they might not make sense are non-standard ones. If we ever were to standardize something like --webkit-scrollbar what would that mean?
<sanketj> q+
<bkardell_> TabAtkins: there are already inheritable properties there
<Rossen_> ack sanketj
<bkardell_> sanketj: This sounds reasonable. The only question I had was is there a usecase that prompted this or is it just for correctness. I would hate to update the spec and then it never gets used
<bkardell_> TabAtkins: the use cases for custom properties are myriad, it's reasonable to think they should work
<leaverou_> Strong +1 for enabling custom properties on every pseudo-element
<bkardell_> sanketj: I guess I am still wondering what the use cases are - in my mind the properties on pseudos are pretty specific. Mostly curiousity
<bkardell_> TabAtkins: Custom properties do nothing on their own, but they empower a million things - so they're always going to be hard to talk about like that
<bkardell_> sanketj: fair enough
<bkardell_> +1
<bkardell_> Rossen_: any objections?
<bkardell_> Rossen_: resolved to support custom properties on all pseudo elements
<TabAtkins> ScribeNick: TabAtkins
<Rossen_> RESOLVED: Add custom properties support to psudo elements