[web-animations-1] Potential misuse of WebIDL spec

[stephenmcgruer]

Filing this to track some concerns from yukishiino@chromium.org raised during a recent review of the Chromium Web Animations implementation (https://chromium-review.googlesource.com/c/chromium/src/+/989261).

With regards to the type of the keyframe argument in the procedure to process a keyframes argument (https://drafts.csswg.org/web-animations-1/#processing-a-keyframes-argument), yukishiino@ said:

"My main concern is whether the spec itself is well-defined or not. Sometimes people define a new web spec that is not consistent with existing web specs. It's easy to make such a mistake (especially when we define things out of the scope of Web IDL). I'm afraid that such a mistake spreads out among web developers and later we find it hard to fix.

FYI, some people want to make it error when an ECMAScript object corresponding to an IDL dictionary has extra properties that are not defined in the IDL dictionary. This feature could be introduced depending on the spec discussion. Such a feature might conflict with this special use case.

So, I wanted you to be aware of what you're doing and its risk."

My personal opinion is that the largest risk here would be the BasePropertyIndexedKeyframe/BaseKeyframe dictionaries, as I think everywhere else (outside of the non-normative information section) we use direct objection manipulation APIs which are still valid even if the object isn't a Dicitonary (e.g. "Let method be the result of GetMethod(object, @@iterator).", "Let raw value be the result of calling the [[Get]] internal method on keyframe input", etc).

I don't think it's worth replacing the BasePropertyIndexedKeyframe/BaseKeyframe dictionaries at this point, but if needed we could rewrite it to just use object APIs.

[stephenmcgruer]

Perhaps we should have used the following syntax for the Keyframe dictionary:

dictionary Keyframe {
double? offset = null;
DOMString easing = "linear";
CompositeOperation? composite = null;
record<DOMString, DOMString> properties;
};

But that ship has long sailed by now; animate() is used on like 4% of the web and we would likely never be able to deprecate the Keyframe syntax. (https://www.chromestatus.com/metrics/feature/timeline/popularity/773)

[birtles]

I'm not sure what the specific ask is in this issue?

The spec was thoroughly reviewed by the two WebIDL editors at that time: heycam and bz and written in the hope that in future this sort of API could be expressed using vanilla WebIDL.

Is that now possible with record types?

[stephenmcgruer]

I don't think there's a specific ask; I was mostly trying to make sure that Yuki's comments didn't disappear after the particular code review was over.

I think the closest thing to an 'ask' here is a warning that the WebIDL spec may change to 'make it error when an ECMAScript object corresponding to an IDL dictionary has extra properties that are not defined in the IDL dictionary.'. We would have to rewrite a bit of Web Animations spec in that case.

Feel free to close if you don't think there's value in this; it can live in the closed issues as history :).

[tabatkins]

There is no chance of IDL dictionaries making that sort of change. It would be a major breaking change across dozens of APIs.

[birtles]

Alright, I'm going to close this for now.