Re: [css-ui-4] caret-animation

On Tue, Aug 4, 2015 at 3:54 PM, Florian Rivoal <florian@rivoal.net> wrote:
> 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.

With the overarching caveat that UAs are allowed to completely ignore
any aspect of the caret-* properties for accessibility purposes, I'd
like a blink value as well, just for clarity.

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

Any example of this blink-between-colors behavior?  I don't think I've
ever seen it.

> 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,

I see this reasonably often in text editors, at least as an option, so
I'd prefer to have it.  Call it "fade", I suppose.

> 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

I prefer this.  There's no particular reason for an author to care,
and violating platform expectations seems worse here.

~TJ

Received on Tuesday, 4 August 2015 23:40:27 UTC