Intent to Ship: CSS Highlight Inheritance

[Stephen Chenney]

Contact emails

sche...@chromium.org

Specification

https://drafts.csswg.org/css-pseudo-4/#highlight-cascade

Summary

With CSS Highlight Inheritance, the CSS Highlight pseudo classes, such as ::selection and ::highlight, inherit their properties through the pseudo highlight chain, rather than the element chain. The result is a more intuitive model for inheritance of properties in highlights. Specifically, "When any supported property is not given a value by the cascade ... its specified value is determined by inheritance from the corresponding highlight pseudo-element of its originating element’s parent element." (https://drafts.csswg.org/css-pseudo-4/#highlight-cascade)

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The feature is still under implementation in other browser engines, but the standards are well developed and there is general agreement on the spec. I think compat risk is very limited at this time.

Gecko: Neutral (https://github.com/mozilla/standards-positions/issues/548) emilio@ is active in standards discussions on the issues, but I am not aware of implementation. https://bugzilla.mozilla.org/show_bug.cgi?id=1703963 https://bugzilla.mozilla.org/show_bug.cgi?id=1703961

WebKit: In development (https://github.com/WebKit/standards-positions/issues/95) I have a private email from the Apple engineer tasked with implementing. I don't want to reveal PI.

Web developers: Developer ergonomics is the primary concern motivating highlight inheritance. See https://github.com/w3c/csswg-drafts/issues/2474 for the initial spec discussion related to the behavior of ::selection. See https://bugs.chromium.org/p/chromium/issues/detail?id=1490471 for an example of a user seeing unexpected behavior without this feature.

Other signals:

Ergonomics

None.

Activation

No. This reflects the already active behavior for ::selection in Firefox and the already used behavior for ::highlight, ::spelling and ::grammar.

Security

There are no security risks.

WebView application risks

None

Debuggability

Devtools supports highlight pseudos and correctly shows the inheritance chain.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

There are no cross-platform issues with implementation and no reason to discriminate on platform.

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/css/css-pseudo?label=experimental&label=master&aligned highlight-cascade-* covers this functionality. There are additional WPT that make use of the feature in https://wpt.fyi/results/css/css-highlight-api?label=experimental&label=master&aligned

Flag name on chrome://flags

experimental-web-platform-features

Finch feature name

HighlightInheritance

Non-finch justification

The feature was enabled as experimental way back in M111 and stayed that way until M116 when it was switched back to test, and it is back on experimental for M118. Developers have significant experience with the feature enabled via experimental web platform features. There is no value to running a finch trial given the large amount of existing experience with the feature.

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop	120
DevTrial on desktop	118

Shipping on Android	120
DevTrial on Android	118

Shipping on WebView

120

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5090853643354112

Links to previous Intent discussions

Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/BbvI5VAguvk

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Tue, Oct 31, 2023 at 1:45 PM Stephen Chenney <sche...@chromium.org> wrote:

Contact emails

sche...@chromium.org

Specification

https://drafts.csswg.org/css-pseudo-4/#highlight-cascade

Summary

With CSS Highlight Inheritance, the CSS Highlight pseudo classes, such as ::selection and ::highlight, inherit their properties through the pseudo highlight chain, rather than the element chain. The result is a more intuitive model for inheritance of properties in highlights. Specifically, "When any supported property is not given a value by the cascade ... its specified value is determined by inheritance from the corresponding highlight pseudo-element of its originating element’s parent element." (https://drafts.csswg.org/css-pseudo-4/#highlight-cascade)

Blink component

Blink>CSS

TAG review

None

Features are exempt from a TAG review only when another vendor has already shipped them. That doesn't seem to be the case here.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The feature is still under implementation in other browser engines, but the standards are well developed and there is general agreement on the spec. I think compat risk is very limited at this time.

Does this feature change the behavior of existing uses of ::highlight and ::selection? Is there risk from breakage there?

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQfdRQU81Cdm2phXD9f4wktm4f%2BReeYJaYVZKLrt_T4rg%40mail.gmail.com.

[Anders Hartvoll Ruud]

On Tue, Oct 31, 2023 at 1:45 PM Stephen Chenney <sche...@chromium.org> wrote:

runtime_enabled_features.json5 looks like this at the moment:

    {
      name: "HighlightInheritance",
      status: "experimental",
      base_feature: "none",
    },

Let's remove base_feature:"none" before shipping?

 

Non-finch justification

The feature was enabled as experimental way back in M111 and stayed that way until M116 when it was switched back to test, and it is back on experimental for M118. Developers have significant experience with the feature enabled via experimental web platform features. There is no value to running a finch trial given the large amount of existing experience with the feature.

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop	120
DevTrial on desktop	118

Shipping on Android	120
DevTrial on Android	118

Shipping on WebView

120

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5090853643354112

Links to previous Intent discussions

Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/BbvI5VAguvk

This intent message was generated by Chrome Platform Status.

--

[Stephen Chenney]

Answers inline. Regarding Ander's comment on the current base_feature setting: I'll fix that.

Cheers,

Stephen.

On Wed, Nov 1, 2023 at 4:17 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Tue, Oct 31, 2023 at 1:45 PM Stephen Chenney <sche...@chromium.org> wrote:

Contact emails

sche...@chromium.org

Specification

https://drafts.csswg.org/css-pseudo-4/#highlight-cascade

Summary

With CSS Highlight Inheritance, the CSS Highlight pseudo classes, such as ::selection and ::highlight, inherit their properties through the pseudo highlight chain, rather than the element chain. The result is a more intuitive model for inheritance of properties in highlights. Specifically, "When any supported property is not given a value by the cascade ... its specified value is determined by inheritance from the corresponding highlight pseudo-element of its originating element’s parent element." (https://drafts.csswg.org/css-pseudo-4/#highlight-cascade)

Blink component

Blink>CSS

TAG review

None

Features are exempt from a TAG review only when another vendor has already shipped them. That doesn't seem to be the case here.

The feature is in the CSS pseudos spec and has been for quite a while. The CSS Working Group has been discussing issues too and Safari, at least, is implementing according to the spec. I think the ship has sailed for any major revision to the behavior. (For context, there was no feature defined for this change until recently because it was originally viewed as a "make the code implement the spec" change.)

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The feature is still under implementation in other browser engines, but the standards are well developed and there is general agreement on the spec. I think compat risk is very limited at this time.

Does this feature change the behavior of existing uses of ::highlight and ::selection? Is there risk from breakage there?

The change aligns the behavior of ::selection with Firefox. ::highlight is already implemented with this behavior. There was breakage of ::selection due to custom property handling, which was resolved at the spec level and fixed in chromium before sending this intent. No other bugs have come in over the extended period that this has been on for experimental web platform features (since M111).

[Stephen Chenney]

My above comment is wrong: The spec defining this feature does change the behavior of ::selection (not ::highlight) for all browsers. But evidence suggests that the mitigations that sites used to work around the old behavior still work with the new behavior, so breakage is very limited. There was a single source of significant breakage when the feature was first turned on and the spec and code have been changed to maintain the former behavior (related to custom properties on root applying to ::selection). We have had zero other reported bugs from enabling the feature experimentally.

Some history ... The spec was changed in response to an issue where Firefox wanted to un-prefix -moz-selection but was not obeying the old spec. As I understand it, the selection style was checking for ::selection on the selected element, using it if found, otherwise using the root selection styling. All browsers were doing this.

Sites were designed to work around this through the judicious use of ::selection on various elements. That is, put ::selection on anything you wanted a specified selection on, and if the inheritance was wrong, add a more specific ::selection selector. Hence the heavy use of custom properties to keep all these ::selection declarations in sync. You can see this, for example, on GitHub where they define ::selection for an element, element > span, and element > span > span, and again for light and dark mode. Sass even has an operator with a comment on it saying they would remove it if the spec is fixed.

This intent to ship does not break sites that have taken this approach. Specific selectors for ::selection will resolve to the same properties as they do now. The improvement is that "element > span::selection" and "element > span > span::selection" can now be removed in favor of just "element::selection".

[Stephen Chenney]

Note that I have moved the shipping milestone to M121, and have created a TAG review issue.

On Thu, Nov 2, 2023 at 10:07 AM Stephen Chenney <sche...@chromium.org> wrote:

On Wed, Nov 1, 2023 at 11:11 AM Stephen Chenney <sche...@chromium.org> wrote:

Answers inline. Regarding Ander's comment on the current base_feature setting: I'll fix that.

Cheers,

Stephen.

On Wed, Nov 1, 2023 at 4:17 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Tue, Oct 31, 2023 at 1:45 PM Stephen Chenney <sche...@chromium.org> wrote:

Contact emails

sche...@chromium.org

Specification

https://drafts.csswg.org/css-pseudo-4/#highlight-cascade

Summary

With CSS Highlight Inheritance, the CSS Highlight pseudo classes, such as ::selection and ::highlight, inherit their properties through the pseudo highlight chain, rather than the element chain. The result is a more intuitive model for inheritance of properties in highlights. Specifically, "When any supported property is not given a value by the cascade ... its specified value is determined by inheritance from the corresponding highlight pseudo-element of its originating element’s parent element." (https://drafts.csswg.org/css-pseudo-4/#highlight-cascade)

Blink component

Blink>CSS

TAG review

None

Features are exempt from a TAG review only when another vendor has already shipped them. That doesn't seem to be the case here.

The feature is in the CSS pseudos spec and has been for quite a while. The CSS Working Group has been discussing issues too and Safari, at least, is implementing according to the spec. I think the ship has sailed for any major revision to the behavior. (For context, there was no feature defined for this change until recently because it was originally viewed as a "make the code implement the spec" change.)

TAG Review Issue: https://github.com/w3ctag/design-reviews/issues/914

[Mike Taylor]

Thanks for the detailed explanation of compat and for filing a TAG review. The risk of breakage seems low (and I suppose we'll learn how true that is as the change rides the trains), and breakage in this case would just be cosmetic (unless someone is doing something really clever).

LGTM1 to ship. Good luck. :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQV-S4-w5nen9dWqeGRjSx_ietab3MzfF%2B-UdikH-8Hmw%40mail.gmail.com.

[Daniel Bratell]

LGTM2

You may want to ping the Mozilla standards position issue and let them know that we are close to shipping. It looks like they forgotten it.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b0b3fb6e-bc93-4823-a9e8-d3e7f8e4a388%40chromium.org.

[Yoav Weiss]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQfdRQU81Cdm2phXD9f4wktm4f%2BReeYJaYVZKLrt_T4rg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQV-S4-w5nen9dWqeGRjSx_ietab3MzfF%2B-UdikH-8Hmw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Stephen Chenney]

Update: Due to breakage of the Wordpress editor, and a couple of other sites, we plan to delay the Stable ship milestone to 122.

I'll update the status entry etc.

Stephen.

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQfdRQU81Cdm2phXD9f4wktm4f%2BReeYJaYVZKLrt_T4rg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQV-S4-w5nen9dWqeGRjSx_ietab3MzfF%2B-UdikH-8Hmw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike Taylor]

Thanks for the update. I might have jinxed it when I said "breakage in this case would just be cosmetic (unless someone is doing something really clever)"... I hadn't considered editor use cases.

Do you think this will ever be shippable, even with a gutenberg update? I would imagine old versions stick around for a very long time.

[Stephen Chenney]

I think we will be able to ship it eventually, and there is active work to get cross-browser compat too. For older browsers I believe there is a simple addition to the CSS for sites that will render the feature moot in most cases, though I am waiting on a site to try it and verify.

Interestingly, the problem with the Wordpress editor is due to code that works around a Safari selection bug. Selection behavior is already an area with incompatibilities, hence the spec work around this feature, and I think it's worth suffering through this release as a step toward a more compatible future.

Cheers,

Stephen.

[Stephen Chenney]

The CSS Highlight Inheritance feature for ::selection has been enabled again. Changes to the spec and code address the bulk of previous breakage, and we have multiple blog posts around the changes, and DevRel are very much in the loop. The Wordpress issue from the previous attempt has been fixed.

Cheers,

Stephen.