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.

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

Standardized Cascade of CSS Highlight-Pseudos #834

Closed
BenjaminAster opened this issue Oct 8, 2024 · 4 comments
Closed

Standardized Cascade of CSS Highlight-Pseudos #834

BenjaminAster opened this issue Oct 8, 2024 · 4 comments
Labels
focus-area-proposal Focus Area Proposal

Comments

@BenjaminAster
Copy link

BenjaminAster commented Oct 8, 2024

Description

The behavior of the inheritance of CSS properties for CSS highlight pseudo-elements (e.g. ::selection) of browsers today does not match the specification. Chromium is planning to ship this in v131 while Firefox and WebKit do not have an (experimental) implementation yet.

The way browsers currently handle highlight inheritance is that the highlight pseudo of any element directly inherits from the element itself:

<html>::selection  <-----  <html>
                             |
                             v
<body>::selection  <-----  <body>
                             |
                             v
<div>::selection  <------  <div>

However, in the specification, the highlight pseudos should inherit applicable properties from the parent's highlight pseudo while certain properties needed to resolve some values (e.g. custom properties, font-size, line-height, etc.) should be copied from the originating element:

                    (only some properties)
<html>::selection  <-----------------------  <html>
        |                                      |
        v           (only some properties)     v
<body>::selection  <-----------------------  <body>
        |                                      |
        v           (only some properties)     v
<div>::selection   <-----------------------  <div>

From a web author's perspective, this means that with the standardized version, a selector like div::selection would be enough to style all selections inside of a <div>, instead of the ugly div::selection, div ::selection selector that is needed today when wanting to style the selection of all text in the <div>, even text nodes that are direct children.

Additionally, with what is implemented in browsers today, nesting different highlight-pseudo stylings becomes very clumsy; e.g. something like

#outer ::selection { color: red }
.inner ::selection { color: blue }

does not work since the first selector has higher specificity than the second one, thus all selected text will always be red, even when inside an .inner container. (Note also that if those elements contain text nodes as direct children, the selectors would have to be #outer::selection, #outer ::selection etc., as mentioned before.) With the standardized version, this would be written as

#outer::selection { color: red }
.inner::selection { color: blue }

and everything would work as expected.

Note: This issue was later edited to reflect a spec change, as noted by @fantasai.

Specification

Additional Signals

Related CSSWG GitHub discussions:

Browser bugs:

See also:

@fantasai
Copy link

Note that there were later changes to the spec, resulting in a split model: properties applicable to highlights inherit through the highlight tree, but properties that don't (but are needed to process those that do, e.g. custom properties) are copied from the originating element. See discussion in w3c/csswg-drafts#7591 (comment). CC @schenney-chromium @delan

@schenney-chromium
Copy link

It would be good for interop and likely be only resource limited in terms of getting the work done. WebKit made some progress in implementing but did not complete the work. Firefox was the original impetus for standardizing the selection inheritance behavior.

@wpt-interop
Copy link
Collaborator

Thank you for proposing Standardized Cascade of CSS Highlight-Pseudos for inclusion in Interop 2025.

We wanted to let you know that this proposal was not selected to be part of Interop this year.

On behalf of the entire Interop team, thank you for submitting this proposal for consideration. We got many more proposals than we could include in this year's project, necessitating some difficult choices. Please note this should not be taken as a comment on the technology as a whole, or our willingness to consider it for Interop in the future. We appreciate the work you put into your proposal, and would welcome your participation in future rounds of Interop.

For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2025.

Posted on behalf of the Interop team.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
focus-area-proposal Focus Area Proposal
Projects
Status: Done
Development

No branches or pull requests

6 participants