Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[css-pseudo] highlight pseudos and custom properties #6264

Closed
May 3, 2021 · 7 comments
Closed

[css-pseudo] highlight pseudos and custom properties #6264

May 3, 2021 · 7 comments
Labels
Closed Accepted by CSSWG Resolution css-pseudo-4 Current Work

Comments

Copy link
Contributor

May 3, 2021 •
edited
Loading

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.
Copy link
Contributor Author

(ping @frivoal, or maybe @fantasai?)

@tabatkins
Copy link
Member

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. ^_^)

If so, does the rule stating that non-inherited properties are to be treated as inherited, apply to registered custom properties where inherit = false?

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.)

@tabatkins tabatkins added the css-pseudo-4 Current Work label May 20, 2021
Copy link
Contributor Author

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
Copy link
Member

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?

Copy link
Contributor Author

Are there any pseudos in which custom properties should not be allowed?

I’m not aware of any, for what it’s worth, but maybe some of the other members can say for sure.

@Loirooriol
Copy link
Contributor

Hm, we should make sure the same applies to other non-tree-abiding pseudos; custom properties should always be available.

And also to tree-abiding ones like ::marker. They aren't listed in https://drafts.csswg.org/css-lists/#marker-properties

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed highlight pseudos and custom props, and agreed to the following:

  • RESOLVED: Add custom properties support to psudo elements
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

@mozilla-apprentice mozilla-apprentice mentioned this issue Jun 30, 2021
Open
Merged
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted by CSSWG Resolution css-pseudo-4 Current Work
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@frivoal @LeaVerou @tabatkins @Loirooriol @css-meeting-bot