Re: [css-ui-4] caret animations

On Tue, Jun 30, 2015 at 12:13 PM, Florian Rivoal <florian@rivoal.net> wrote:
> 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.

I don't think it's worth it, but if anyone cares, I wouldn't object.

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

Yes, I think we should.  Otherwise we have to define the relative
cascade of animations and caret-animations.

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

Actually, rather than having @keyframes take both "normal" animated
properties and caret-* properties, but only one or the other is used
in a given animation, it might make sense to actually split this
apart, so you have @caret-keyframes.  Then it's simpler - caret-*
properties are illegal in @keyframes, non-caret-* properties are
illegal in @caret-keyframes.

I haven't thought through the further complications of this.

~TJ

Received on Tuesday, 30 June 2015 20:29:23 UTC