[css-pseudo] highlight pseudos and custom properties #6264
Comments
|
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. (
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.) |
|
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. |
|
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? |
I’m not aware of any, for what it’s worth, but maybe some of the other members can say for sure. |
And also to tree-abiding ones like ::marker. They aren't listed in https://drafts.csswg.org/css-lists/#marker-properties |
|
The CSS Working Group just discussed
The 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 |
https://drafts.csswg.org/css-pseudo-4/#highlight-styling
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.
The text was updated successfully, but these errors were encountered: