[w3ctag/design-reviews] CSS ::selection Inheritance Model (Issue #914)

こんにちは TAG-さん!

I'm requesting a TAG review of changes to the CSS cascade model for the ::selection pseudo class, also known as CSS Highlight Inheritance because it applies to all highlight pseudos (of which ::selection is the only one that has been around long enough to have back compatibility concerns).

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

  - Explainer¹ (minimally containing user needs and example code): [[url]](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/highlight/explainer.md)
  - Specification URL: [[spec url]](https://drafts.csswg.org/css-pseudo/#highlight-cascade)
  - Tests: [[wpt folder(s), if available]](https://wpt.fyi/results/css/css-pseudo?label=master&view=subtest)
  - User research: [[url to public summary/results of research]](https://github.com/w3c/csswg-drafts/issues/2474) 
  - Security and Privacy self-review²: [[url]](https://docs.google.com/document/d/1XbeJFMHeyHNJ_jSlWLd2hs9JyolNy5Ub5sCzk44mIB0/edit?usp=sharing)
  - GitHub repo (if you prefer feedback filed there): [url]
  - Primary contacts (and their relationship to the specification):
      - [Stephen Chenney](https://github.com/w3ctag/design-reviews/issues/%5Bschenney-chromium%5D), [Igalia] Implementor
      - [Elika J. Etemad](https://github.com/w3ctag/design-reviews/issues/%5Bfantasai%5D), [Apple] Spec editor
  - Organization(s)/project(s) driving the specification: Bloomberg, Microsoft, Google
  - Key pieces of existing multi-stakeholder review or discussion of this specification: https://github.com/w3c/csswg-drafts/issues/2474 and associated CSS WG discussions
  - External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5090853643354112?context=myfeatures

Further details:

  - [ Yes ] I have reviewed the TAG's [Web Platform Design Principles](https://www.w3.org/TR/design-principles/)
  - Relevant time constraints or deadlines: WebKit are implementing and chromium would like to ship
  - The group where the work on this specification is currently being done: CSS
  - Major unresolved issues with or opposition to this specification: None. 
  - This work is being funded by: Bloomberg

You should also know that...

We are requesting TAG review because this is a potentially site breaking change despite being a fix for a problem with the spec. We believe the impact on existing sites is limited based on several months of experimental testing in Chrome.

The spec defining this feature does change the behavior of ::selection (not ::highlight) for all browsers. But evidence suggests that the mitigation 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 change does not break sites that have taken the approach above. 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".

We'd prefer the TAG provide feedback as (please delete all but the desired option):

  💬 leave review feedback as a **comment in this issue** and @-notify [schenney-chromium]



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/914
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/914@github.com>