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

> On 05 Aug 2015, at 01:39, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> 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.

UAs can achieve that by putting a !important value on the caret properties in the UA or user style sheet based on user settings (or behaving as if they did), and I am OK with having a note making it clear.

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

Bloomberg gave a demo of the Bloomberg Terminal when we were in NY, and it had a caret blinking between light blue and dark blue (on a non blue background).


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

Assuming willingness to implement, I'm ok with that.

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

I am probably fine with this.

If you're writing a web app which manages multiple window-like things, and focus can change between them, you might want to have different conventions from the host OS, since you're effectively being the platform yourself.

But that is a fairly unimportant aspect of a rare use case, so not supporting it is fine.

 - Florian

Received on Sunday, 16 August 2015 15:40:19 UTC