Re: [csswg-drafts] Allow developers to set the text color under the caret when caret-shape is block (#13723)

Currently, the spec has a requirement for the opposite situation: if you leave the caret-color on auto, the user agent is supposed to (and does) pick a reasonable color so that the caret contrasts with the text and is visible. But there is currently no requirement to adjust the text to contrast with a caret whose color was explicitly set, nor a way to let the author specify which color they want for the over-the-caret text.

Here's a suggestion that I think would address that:

`caret-color: auto | <color> [ normal | auto | <color> ]?`

* if only one value is specified (`auto` or `<color>`) it's the current behavior.
* If two values are specified, the first one, like now, is the color of the caret itself, and the second one tells us about the color of the text *when it overlaps with the caret*. The values have the following meaning:
  * `normal`: the text does not change color when it overlaps with the caret (this is the default behavior when the second value is omitted)
  * `auto`: the user agent automatically picks a color which contrasts well with the color of the caret
  * `<color>` an explicit color to use for the text when it overlaps with the caret.

So you can do:
```css
  background: #00ffff;
  color: #770000;
  caret-color: #770000 white;
  caret-shape: block;
```
and then you have dark red text with a dark red block caret on a cyan background, but when the caret overlaps with a character, then that character turns white.

And if you want good contrast, but don't care about the color, you just go with `caret-color: #770000 auto;`

Putting the two in the same property makes it easy to make sure they get set together, and also, if the caret color is animated, makes it easy to animate the two together, which is necessary for good contrast.

There's an important subtlety around what we mean by "overlap", which may significantly impact implementation complexity. I'd say:
* if the `caret-shape` is `bar` or `underscore`, no character is considered to overlap the caret for the purposes of coloring.
* if the `care-shape` is `block`, the next visible character following the insertion point, which is the one used to determine the width of the caret, is considered to be "overlapping" with the caret, and uses the new value of `caret-color` to determine it's color.

I think we may also _allow_ the user agent to do a visual intersection check, and pick which color to use based on whether text is visually intersecting with the caret or not. But I would not require that.
* It would be useful because, _in the general case_, due to italics, ascenders , decenders, diacritics, or just interesting shapes, characters may leak in or out of the caret, and for ideal contrast, you'd want the bits leaking out or in to be painted in with the ideal color.
* I wouldn't require it because implementation of painting parts of characters in different colors is likely to be pretty complicated, and _in the typical case_ unnecessary, as the block caret will usually cover all (or close to all) of the relevant character.

Possible tweaks / simplifications:
* don't include a `normal` keyword. That behavior is available with `caret-color: blue currentColor` anyway
* make `auto` the default, rather than `normal` (or `currentColor`), because good contrast is something we should get by default and opt out of in special cases, rather than something we opt into. Then again, since the UA is now in charge of the color, this introduces the risk that the UA will pick a color different from the normal color of the text, even if the color of the text may have been considered appropriate and sufficiently contrasty by the author. We may have compat constraints about this.

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


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

Received on Thursday, 26 March 2026 08:21:16 UTC