[css-pseudo] [css-highlight-api] defaults and inheritance for ::spelling-error + ::grammar-error + ::highlight

[delan]

• https://drafts.csswg.org/css-pseudo-4/#highlight-pseudos
• https://drafts.csswg.org/css-highlight-api-1/#default-styles

Problem 1: UA default highlight colors

(this problem turned out to effectively be the same as #6774)

If I understand conventional behaviour and #highlight-ua-styles correctly, the intended default behaviour of ::spelling-error and ::grammar-error is to decorate the highlighted text without changing the foreground color.

Similarly, if I understand #6375 correctly, the intended default behaviour of an unstyled ::highlight is to yield no visible change in rendering, or at least not change the foreground color.

But given the following statements…

1. Highlight pseudo computed styles inherit all properties from the same highlight’s styles in the parent, eventually defaulting to initial values (#highlight-cascade). Used values can differ due to paired cascade ([css-pseudo] clarify paired-cascading behavior #6386).

2. color:currentColor is the only way to grab the foreground color from lower layers, that is to say, “don’t change the color compared to if this text was unhighlighted” (#highlight-text).

3. The initial value of color is a UA-defined ordinary color (css-color-3) or CanvasText (css-color-4), not currentColor.

4. There are no recommended UA default highlight colors for ::spelling-error + ::grammar-error (#highlight-ua-styles), be they magic used colors via paired cascade or just declarations in the UA stylesheet, and UA default highlight colors are forbidden for ::highlight as of [css-highlight-api-1] Specify that custom highlights have no UA styles #6375 #6534 (#default-styles).

…then by default, these three highlight pseudos will effectively reset the foreground color of highlighted text to initial (usually black), which is probably not what we want.

Problem 2: custom highlight inheritance clause

As of #6534, #default-styles says:

A custom highlight pseudo-element inherits the styles of its originating element.

I don’t think this really makes sense, because taken at face value, it essentially clobbers highlight inheritance (#highlight-cascade) in favour of the legacy behaviour (like how ::selection currently works in most impls).

Possible solutions

(see #6774 for solution to problem 1)

I think #highlight-ua-styles and #default-styles should explicitly recommend (or require) UA defaults for these three highlight pseudos that behave like color:currentColor. I believe the defaults should come from magic paired cascade, not UA stylesheet rules, to keep paired cascade as consistent and predictable as possible.

No change is needed for the other highlight color (background-color), because its initial value is transparent.

I think the spec text in Problem 2 should be removed.

[dandclark]

Thanks for pointing this out!

For custom highlights at least, the original intention of the custom highlight #default-styles was indeed for an unstyled ::highlight to yield no visible change in rendering. I had written the spec text with the legacy ::selection behavior in mind, so it doesn't fit with the new #highlight-cascade behavior.

Maybe we could change #default-styles to something like the following, borrowing some language from #highlight-text:

If the author does not specify a custom highlight pseudo-element's color, the text is painted using the color of the next highlight pseudo-element layer below, or if none exists, the colors that would otherwise have been used (those applied by the originating element or an intervening pseudo-element such as ::first-line or ::first-letter). If the author does not specify a custom highlight pseudo-element's background-color, the UA must paint the highlight pseudo-element's background using the value 'transparent'.

[delan]

I had written the spec text with the legacy ::selection behavior in mind, so it doesn't fit with the new #highlight-cascade behavior.

Fair enough, that makes sense. I think that proposed wording is a good start, but I think it fails to account for the special relationship between ‘color’ and ‘background-color’ (paired cascade), and suffers from the same problems as “specified by the author” does in #highlight-cascade (#6386).

e6ec959ad9fb3 attempts to word this in a way that builds on the clarifications I’ve proposed in #6665, what do you think?

[dandclark]

Ah, I'd missed that #6665 was also addressing this for custom highlights. It looks great to me!

[astearns]

We probably don’t need agenda time for this if @frivoal and/or @fantasai could review the PR

[delan]

#6665 makes the edits for these questions.