[css-ui-4] caret-animation

We've previously said that explicit control of the
caret's blink timing was a bad idea[1], and that
caret-only full blown animations were overkill[2],
so I took a step back, looked at the use cases, and
here is a simple version that let's us cover the
main cases of wanting to control the caret's
animation, and that can be extended later to cover
more should we want to.

The basic use cases are:
1) Keep the system default behavior, which is
typically blinking
2) Have a fixed (non blinking) cursor, either because
of an esthetic choice (often used in terminal-like
styling), or as an accessibility one (blinking things
can be distracting to some[3])

These are simply solved by:

  caret-animation: auto | fixed

  auto:
    Caret animation is up to the UA, and should
    follow platform conventions and settings.
    Typically rendered as a blinking caret.
  fixed:
    The UA must not animate the caret.

Maybe we want "blink" as an explicit value as well,
so that authors can ask for blinking even on
platforms/situations where that auto wouldn't
do that.

After that, there are some occasional request
for more fancy things, mainly:
- fading instead of blinking, or appear-then-fade-out...
- alternating between 2 colors, rather than between
a single color and transparent. (Bloomberg wants this effect).

I am not sure these need solving right now, since as
has been mentioned before it is always possible (if
cumbersome) to use animations. But should we want to,
the first one can simply be done by adding more
keywords to caret-animation, and the second one by
extending caret-color into
  caret-color: auto | <color>{1,2}
or
  caret-color: auto | <color>+
giving you colors to alternate between/cycle through.
Having these would be nicer than rolling your own
animations, since they'd still be respect system timing,
but they are for rare use cases.

Any opinion for or against the design, and for or against
inclusion of these fancier options now?

Finally, Bert (I think) raised a point I've been wondering
about. In all browsers I know of, when the text field is
out-of-focus, as well as when the text field would be
focused except that the window itself is not, the caret
is simply invisible. That is however not the only option
out there, and you can for example see that the OS X
Terminal has a visible hollow-box non-blinking caret when
not focused.

This made me wonder, in the web platform, how do we explain
the caret's  invisibleness when not focused, and can we
override it?
 a) That's how our carets work
    + simple
    - cannot override
 b) It's part of auto
    + can override
    ? Impossible to get blinking caret in out-of-focus fields
      (unless we add an explicit blink value)
    - You need to use :focus in the selector when you use
      caret-animation in the common case where you don't want
      do change the out-of-focus behavior
 c) It's done in the UA stylesheet (e.g. ":not(:focus)
    {caret-color: transparent}")
    + can override
    ? Possible to get blinking caret in out-of-focus fields
    - You need to use :focus in the selector when you use
      caret-animation in the common case where you don't want
      do change the out-of-focus behavior
  d) caret-animation takes 2 values, one for when focused,
     one for when not focused, and the optional second one
     defaults to "invisible"
     + can override
     + behaves well in the default case of not
       wanting to override
     - feels overkill and a bit of a kludge

I don't like b) or c) as they make the common case more
verbose & error prone in favor of the rare case. d) works,
but makes the property significantly more complex for a
rare use case. So I think a) is good enough. And we can
without compat issues extend it into d) later if we really
want to.

 - Florian

[1] https://lists.w3.org/Archives/Public/www-style/2015Jun/0242.html
[2] https://lists.w3.org/Archives/Public/www-style/2015Jul/0225.html
[3] http://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-pause.html

Received on Tuesday, 4 August 2015 22:55:19 UTC