W3C home > Mailing lists > Public > www-style@w3.org > June 2015

[css-ui-4] caret animations

From: Florian Rivoal <florian@rivoal.net>
Date: Tue, 30 Jun 2015 21:13:55 +0200
To: www-style list <www-style@w3.org>
Message-Id: <8ECE5E68-CC13-435E-9672-D9F7FFFA4E25@rivoal.net>
From the minutes of the NY F2F, regarding caret blinking and animations:

> fantasai: I do think the blink-time property needs improvement.
> <smfr> blink time is system-controlled. why should authors be able
>        to change it?
> fantasai: The only thing you can animate is the color, really.  I
>           would suggest defining the animation using the standard
>           animations syntax, but invoke it with a special caret-
>           animation property.
> fantasai: That way it won't interfere with regular animations, you
>           won't have the cascading problem, but you can still use
>           the standard animation syntax.
> fantasai: And we can have keywords for the common cases.
> fantasai: That would allow both controlling the blink time, also
>           animating between blue and dark blue, as mentioned.
> Florian: I'm happy to explore something along the lines of what
>          fantasai said.

Just as a reminder, caret-blink-time is currently specified like this:
  caret-blink-time: auto | <time>{1,2}
auto gets you the platform/UA default, and one time is how long it stays on, the other how long is stays off, both being equal if you specify only one time, and if the second value or both values are 0, it's always on. The expectation being that if you want to do custom animations, you'll do "caret-blink-time:0" and use the animation properties and @keyframe.

If I understand fantasai correctly, she is suggesting something like:

caret-animation: blink | static | <animation>

Where blink and static are convenience shortcuts that could be expressed in terms of animation, and where <animation> is exactly the same syntax as regular animations.

I think this is a good idea, and the fact that we can make this property inherited, like other caret properties is a major win. The other benefit being that you can now set an animation on an potentially editable element without having to wonder whether you just blew up the animation on the element's caret.

Should caret-animation be a standalone property, or a shorthand of caret-animation-*? My guess is that longhands are not worth it in this case, but if someone thinks otherwise, please let me know.

We also need to say that caret-animation inside an @keyframes has no effect, and that properties other than caret-* used in an @keyframes invoked from caret-animation have no effect.

Should we ban caret-* properties from being used in a traditional animation? I don't think we need to, but if not, we need to define what happens when they are animated at the same time through both animation and caret-animation. caret animation wins?

Also I wonder if we need any adjustement on the OM/event side of things as well. Not on the OM as far as I can tell, but maybe something in events would be useful.

I'll go ahead and update the spec based on this, with issues for the open questions.

 - Florian
Received on Tuesday, 30 June 2015 19:14:26 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:51 UTC