Re: [css-ui-4] caret animations

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

Which isn't particularly hard. Just insert them between step 5 and 6 here:
http://www.w3.org/TR/css-cascade-3/#cascade-origin

This makes me think that regardless of what we pick for the question above, "caret-animation:blink" (and "caret-animation:static" if we have it) are not actually convenience shortcuts to animations you could define yourself. If they were, caret-color would never take effect. That doesn't invalidate the proposed syntax, but I need to be careful how I word this.

Banning caret-color from normal animations would make it the only non animatable <color> property, while keeping it indirectly animatable by setting caret-color to currentColor and animating the color property (this works today). This feels weird, and probably requires extra code depending on how your browser engine is coded (meaning extra bugs, etc), and isn't very nice for learnability.

Also, keeping it as a regular animation lets you do things you cannot do with caret-animation. Let's say you are perfectly happy about leaving the blinking up to platform defaults, but you feel like you should have a caret going through the colors of the rainbow, to keep things topical with the news. animation can do that, caret-animation cannot, as you'd you need to do the blinking yourself. 

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

The more separate the code-paths are, the more likely we are to have bugs, delays in implementations, or (accidental) drifting apart when something gets added to animations but an implementer forgets to (or does not prioritize) update the caret variant accordingly.

Also, it means we need to reflect this duplication in the OM. Which is not hard, but the same concerns about bugs, delays, and drifting apply.

Both when it comes to CSS and to the OM, it seems to me that this would be a mild but non-zero hindrance on learnability.

 - Florian

Received on Wednesday, 1 July 2015 09:41:27 UTC