Re: [csswg-drafts] [css-pseudo] Allow custom Properties in ::selection pseudos (revisited) (#11317)

The correct proposed language is "All custom properties inherit from the originating element" combined with re-allowing custom properties on the highlight itself. Much of the confusion here results from my relative inexperience writing spec PRs.

The proposal is the former resolution, Issue #9909, plus re-allowing custom properties on the highlight itself. The former resolution both banned custom properties on the highlight itself _and_ said inherit from the originating element.

The current spec draft is in fact wrong in that it says both "custom properties are inherited from the originating element" and that they inherit through the highlight cascade. I just updated the PR to fix this. https://github.com/w3c/csswg-drafts/pull/11528

In practice this means custom properties use the long-standing back-compatible browser behavior, while other properties move to the new model. This is done because so much existing selection styling depends on custom properties, and without this custom-property behavior we can never launch the improved highlight inheritance model. We've tried to launch 3 times in Chromium and this issue has tripped us up every time. The current proposal addresses all of the known breaking issues around custom properties (by basically reverting to the old behavior).

For those following along:
* Launch attempt 1 failed because custom properties defined on the root element, as was done on GitHub, for example, were not applying to the selection at all. So we said that the root highlight inherits custom properties from the root element.
* Launch attempt 2 failed because there were developer focused sites telling authors to use custom property inheritance in the element cascade to achieve sensible selection property inheritance. That was great advice, but only copying properties from the root then inheriting through highlights broke that. So we said "no custom properties on highlights at all, just take from originating". Various people were unhappy about the "no custom properties on highlights at all" portion of this but I stupidly did not follow through in investigating the prevalence.
* Launch attempt 3 failed because a widely used CSS package did in fact require custom properties defined on highlights.

Hence this issue and proposed language, which addresses all three failure modes.

From an implementation perspective, the highlight gets a shared copy of all the originating element's variables and then adds in any that the highlight defines. So basically the same as regular custom property inheritance.

If for consistency we really want to have custom properties inherit through the highlight cascade we would need to split selection out specifically, which is argued against above, or support both methods until sites can migrate (i.e. for years). Supporting both requires two sets of custom properties in pseudo highlights and some method for resolving conflicts. That really is something I do not want to do.

-- 
GitHub Notification of comment by schenney-chromium
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11317#issuecomment-2613152280 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 24 January 2025 18:33:23 UTC