[CSS UI-4] caret-animation property

[schenney-chromium]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: CSS UI 4
• Specification or proposal URL (if available): https://drafts.csswg.org/css-ui-4/#caret-animation
• Explainer URL (if available): See the CSS WG Issue
• Proposal author(s) (@-mention GitHub accounts): frivoal
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):
• WebKit standards-position: Pending

Other information

This is already in the spec after the resolution of CSS #9707
My recollection from the CSS WG meeting is that Emilio was OK but the log does not reflect that so I may well be confusing issues.
Chromium intent: https://chromestatus.com/feature/5082469066604544

[emilio]

In general this seems sensible to me, though I'm curious if a11y folks have concerns about this? cc @jcsteh

It should be relatively easy to implement (i.e., Firefox supports ui.caretBlinkTime=-1 to prevent the caret animation).

A few questions I have (and the spec doesn't quite determine unless I'm missing something):

• What happens when you have the caret between element boundaries? i.e. if you have <span style="caret-animation: manual">foo</span><span style="caret-animation: auto">bar</span>, is it well defined which one applies if you're in between the last o and the b? Is it the intention that you take the caret-animation value from the closest editing host (and thus the value on individual <span>s is meaningless?). That's my read from the "applies to" line... But the spec could be more explicit.

• If you apply this property dynamically, When are UAs expected to honor it? Immediately? When the caret moves? Sometime else?

• The spec doesn't seem to consider non-editable caret (like caret browsing which IIRC Chromium also has). Should it?

If you agree these are not defined, it'd be great to open issues about them...

[schenney-chromium]

I was aware that Firefox already supports this as a user setting. It was easy to implement in Blink too.

The spec text mentions this being a a11y benefit for users impacted by motion. That probably applies more to browser like Chrome without user-facing caret blinking controls.

Overall I think the implementation details for caret-animation should match those for caret-color wherever possible because s this feature is intended to improve animated caret-color.

• In Blink the caret is controlled through the selection code and the property value will be taken from the start node of the selection range (which if the selection is a "caret" means the end node is also the start node). Which node that is in the case of two adjoining spans depends on the hit testing and caret positioning code, which is essentially unspecified. Though at the end of the day it is the same as the editing node. I think as a spec issue we would want the behavior to match that of caret-color, which also does't say exactly which node the color should come from.

• In the dynamic case I expect it to be applied no later than the next cycle of caret blinking, regardless of whether the caret has moved. In the Blink prototype I invalidate paint when the property value changes which causes the caret state to update. I would also have been happy implementing it as waiting until the next time the caret on/off timer fired.

• The spec for caret-color does call out "additional things that count as carets". Again I would expect caret-animation to apply whenever caret-color applies (as I think it does with caret browsing when enabled in Chrome).

[jcsteh]

The spec text mentions this being a a11y benefit for users impacted by motion.

It could equally be an a11y detriment, though, if the user has very specific OS or browser settings for blink time, etc. and some site goes and overrides those. Given that certain kinds of blinking can cause severe physical reactions for some folks, this might not be a minor concern. That said, the fact that you can already animate caret-color means this is already possible, though we shouldn't necessarily dig the hole deeper just because the hole has already been dug. :) I guess browsers could choose to ignore this if commanded by the user, just as they can behave specially with forced colors, for example. Does that seem reasonable?

CC @MReschenberg, who has deeper experience and understanding of colour and motion issues than I, in case she has further thoughts.

[emilio]

Yeah so... Caret-color should be handled like other colors in forced-colors mode, probably. And that means that caret-animation: none would unintentionally disable the custom blinking animation altogether for those users which seems unfortunate. It's at least a bit footgunny

[schenney-chromium]

Thanks for the input.

Note the values are caret-animation: auto (browser does what it will) and caret-animation: manual intended to mean the site is manually animating the caret. Which leads me to propose this alternative.

The spec could be changed to say that if you set caret-animation: manual it will only apply if you are actually manually animating the caret. i.e. if you have caret-color set to an animated color. I don't have enough spec experience to know if such a thing would be acceptable, but it could be implemented.

And the a11y use case could be delegated to the browser and/or under the control of prefers-reduced-motion.

I agree that caret-color should be modified by forced-colors.

Thoughts?

A couple of other things:

• There is no MDN page for caret-animation. I'll work on fixing that once we nail down mutually agreeable behavior.
• caret-color: transparent is supported by all browsers which is definitely not good for users if used improperly but is currently used when sites totally override the caret styling by implementing their own caret.