Skip to content

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

Closed

Description

@delan

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.

Activity

  1. dandclark commented on Nov 17, 2021

    @dandclark
    Contributor

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

  2. delan commented on Nov 18, 2021

    @delan
    ContributorAuthor

    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?

  3. dandclark commented on Nov 18, 2021

    @dandclark
    Contributor

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

  4. astearns commented on Dec 7, 2021

    @astearns
    Member

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

  5. delan commented on Oct 6, 2022

    @delan
    ContributorAuthor

    #6665 makes the edits for these questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions