[web-animations] Reject both "float" and "offset" in keyframes object

[BorisChiou]

Based on the spec, we use cssFloat and cssOffset to represent float property and offset property for IDL name conversion. We reject offset if is it not a double value because it is a special attribute in BaseKeyframe. For consistency, maybe we should also reject float in keyframes object, and should only accept cssFloat. (It seems Blink still accept float in keyframes object.)
e.g.

let a = document.body.animate([{ "float": "left" }], 1000);
a.pause();
a.effect.getKeyframes()[0].cssFloat; // Shouldn't be "left".

@birtles If you agree with this, could we add a note in the spec to mention that we reject both offset and float in keyframes object?

[emilio]

if we allow both float and cssFloat we need to define which one wins if you specify both... Blink doesn't implement proper shorting IIRC so they don't deal with it afaict.

[birtles]

Yes, rejecting float seems reasonable to me. I just need to find time to make the edits (thanks to TPAC I'm being overwhelmed with different reviews at the moment).

[emilio]

cc @majido

[birtles]

Actually, this is already covered by the procedure to process a keyframe-like object. That has:

2. Build up a list of animatable properties as follows:
   1. Let animatable properties be a list of property names (including shorthand properties that have longhand sub-properties that are animatable) that can be animated by the implementation.
   2. Convert each property name in animatable properties to the equivalent IDL attribute by applying the animation property name to IDL attribute name algorithm.
3. Let input properties be the result of calling the EnumerableOwnNames operation with keyframe input as the object.
4. Make up a new list animation properties that consists of all of the properties that are in both input properties and animatable properties, or which are in input properties and conform to the <custom-property-name> production.

It only ever does a [[Get]] on the animations in the resulting animation properties list.

So in the test case here:

• animatable properties will include cssFloat (but not float).
• input properties will be [[float]].

So in step 4 animation properties should be empty.

So this appears to be a blink bug. @BorisChiou do you mind adding a WPT for it? Perhaps by adding float to gNonAnimatableProps in processing-a-keyframes-argument-001.html.

[BorisChiou]

OK, I will add some for cssFloat/float in WPT.

[stephenmcgruer]

Will be fixed in Chromium by https://chromium-review.googlesource.com/c/chromium/src/+/1822622