[css-ui-4] inteference with the caret blinking and the ability to animate its color

[frivoal]

Using caret-color, you can change the color of the text insertion caret. Using css animations, you can animate that color. Using this, people could create carets that:

• fade in and out instead of blinking
  (variations around this concept are for instance available in VS Code: https://www.youtube.com/watch?v=Hms3gUBKaVQ)

• alternate between two (or more) colors instead of alternate between visible and invisible, such as a bright and a subdued variant of the same color.
  (This is an effect that can for instance be seen in Bloomberg Terminal https://www.youtube.com/watch?v=MaWWOQgAMLY&t=115s )

Well, you almost could do that, but in practice it doesn't work, because at the same time as you are animating the caret color, it's still blinking. So instead, people who try to do this sort of things hide the caret (by making it transparent), place an empty div where the caret is (and use JavaScript to track it around) just so they can style it. This is cumbersome and brittle.

A while back, we had explored a caret-animation property, with one value (auto) letting the caret blink or animate in whatever way is native to the platform, and one value (we last called it none, but I would actually rather go with manual) making the caret just be the color of caret-color, allowing animations to do their work undisrupted. This would be easy to implement, and would remove the need for complicated workarounds.

I would like to revive this.

(We could also have a couple of convenience values, such as fade or blink, but these don't enable anything that isn't possible with animations once we have manual)

[javifernandez]

I think the idea makes a lot of sense. There is indeed a strong use case on adapting the caret animation to the context of the web content being rendered. Sometimes the default blinking is very annoying and distracting.

This solution would simplify considerably the implementation of those designs, making web author's life easier and better interoperability between browsers.

[progers]

I worry that the potential issues of custom color animations may outweigh the benefits. For example:

• Webkit recently added a special caret for dictation (commit) which has more of a throbbing effect, rather than blinking. It would be difficult to keep a custom color animation in sync with this effect.
• Chromium uses the OS's blink rate setting, and Firefox has a blink rate setting. There is the potential to annoy users if these are not honored.
• A solid caret may confuse users.

Vscode and bloomberg are super customized (e.g., supporting multiple cursors) and are unlikely to use this feature. Are there usecases for custom caret color animations other than editors/terminals?

dictationcaret.mov

[css-meeting-bot]

The CSS Working Group just discussed [css-ui-4] inteference with the caret blinking and the ability to animate its color, and agreed to the following:

• RESOLVED: The caret animation is auto versus none

The full IRC log of that discussion

<Frances> florian: Using the caret-color property that is implemented is an animated property. Could use the wrong blinking between transparent and the color. Proposal is to make it possible, to opt to not animate the caret.
<Frances> Florian: If there is not an override, we need to create a more reliable animation. Use various built in types of animations. Add none and auto.
<kbabbitt> q+
<Frances> florian: Counter point is that sometimes the browser can do things that is not just thinking, if stopping the animations then could lose animating the caret at the same time.
<Frances> Kevin: Could a better property be the caret pseudo element to replace the blinking and a box caret, would it be more extensible?
<Rossen_> ack kbabbitt
<TabAtkins> I think the "people are already just completely replacing the caret, we likely won't make this worse" is reasonable, so adding this won't make things meaningfully worse (and is outweighed by having the native caret be used, which is less janky).
<Frances> Florian: This could possibly expose too much structure, most carets might be simple, might be used in case. Could be a dormant property. Make an explicit not implementing the caret in adding support and being able to add support. Browsers that do not want to yield should be able to not implement the caret
<flackr> q+
<schenney> q+
<Frances> flackr: We have some pseudos to specify only a few properties.
<Frances> Florian: There are some fairly limited carets that exist. Such as both sides of the logical locations. Not sure if a caret pseudo would be the right thing.
<vmpstr> tab, the blinking rate though is something that is (or can be) user set and so ignoring that because author said so seems wrong.. But I agree that if authors already replacing the whole caret, maybe this isn't worse
<Frances> Florian: What does width mean? Multiple pieces? We would need to describe the structure.
<Rossen_> ack flackr
<Frances> Tab: We already have existent proof in manually reimplementing them. It could be less janky with a more correct caret. More people could replace the animation of a caret for the user of a web page.
<Frances> Tab: Leans towards this being a useful thing to specify.
<Frances> Florian: We need to be careful to not interfere in any way in accessibility.
<Frances> Schenney: The most similar pseudo would be spelling and grammar, text browsers render native text-decorations
<Frances> Schenney: We can outline and could put a special caret.
<Frances> PROPOSAL: The caret animation is auto versus none
<Frances> RESOLVED: The caret animation is auto versus none
<Rossen_> github-bot topic end
<Rossen_> github-bot topic: end

[frivoal]

Landed the changes through 58d739b.

Note that I called the non-auto value manual rather than none, as that seems better to avoid confusions that this prevents any animation (it doesn't: it only prevents ua-driven annimations).