Intent to Deprecate and Remove: WebKitAnimationEvent interface

[Stephen Mcgruer]

Primary eng (and PM) emails

smcg...@chromium.org

Summary

Deprecate and remove WebKitAnimationEvent interface. WebKitAnimationEvent is the prefixed version of AnimationEvent. AnimationEvent is the event interface used for events relating to CSS Animations (e.g. animationstart).

The ability to create WebKitAnimationEvent from document.createEvent was removed last year, and WebKitAnimationEvent has been an alias of AnimationEvent for a long time (multiple years):

> window.WebKitAnimationEvent

ƒ AnimationEvent() { [native code] }

The only remaining way a web developer can interact with WebKitAnimationEvent is to access it via window, to either check it exists or to create an event from it. It makes no sense for a web developer to manually create such an event (that I am aware).

I would prefer to remove immediately (targeting M71), but would also be happy to land a deprecation warning for M71 and remove in M72.

Motivation

WebKitAnimationEvent has been fully replaced by AnimationEvent. The prefixed form is only supported in Safari. Firefox and Edge only support the un-prefixed AnimationEvent.

Interoperability and Compatibility Risk

Hopefully low, when viewed with some careful reasoning :). The UseCounter is high, at ~2.9% of the web. However, I believe most uses are either browser or support detection.

An analysis of HTTP Archive for this feature shows 744 hits for WebKitAnimationEvent appearing in a response body. Breaking them down showed:

• 215 results (30% of total) from 'blueconic', which is a fingerprinting library.
• 123 results (~16% of total) from 'celtra', which appears to be advertising library. The code in question fills a translation dict to map 'transitionstart' --> 'webkitAnimationStart'/etc for browsers that only support 'webkitAnimationStart' (so no browsers). Overall behavior will not change from removal, library will just use 'animationstart' instead of 'webkitAnimationStart'/etc.
• 97 hits (~13% of total) from 'design-toolkit_min' (unknown library). Use of WebKitAnimationEvent appears to be for browser detection, but the check would fail on every browser I know of already: var u = t.WebKitAnimationEvent && !t.WebGLActiveInfo ? true : false;
• 55 hits (~7%) of total from 'lfm' (unknown library). Used to decide whether to use 'webkitAnimationEnd' or 'animationend', this will continue to work after removal.
• 36 hits (~5%) of total from 'aw_mobile/navigation.js'. It is not clear what the usage is; there is branching logic which does different things based on whether WebKitAnimationEvent exists, this may break after removal.
• 30 hits (~4%) of total from 'alicdn.com/ae-ams-ui' (unknown library). Used to decide whether to use 'webkitAnimationEnd' or 'animationend' (but sensibly checks for the unprefixed version first, good web dev!), this will not change after removal.
• The remaining are split between the following libraries, which have not been closely analyzed: avalon (28 hits), ae-channel-ui-voucher_js (23 hits), rfihub.net (16 hits), unclassified (128 hits).

Taking 5 random samples from unclassified:

$ ls unclassified/ | sort -R | head -n 5

WebKitAnimationEvent.230.txt

WebKitAnimationEvent.218.txt

WebKitAnimationEvent.381.txt

WebKitAnimationEvent.006.txt

WebKitAnimationEvent.528.txt

WebKitAnimationEvent.230.txt - same as aw_mobile/navigation.js logic. Appears to come from a jQTouch library. Looking at the latest version of this library (http://jqtjs.com/preview/src/jqt.js) it still uses this logic and will break (the library also hasn't been changed in 4 years). Library author should change to using the unprefixed events, which both Chrome and Safari support (and means their library would work on e.g. Firefox mobile).

WebKitAnimationEvent.218.txt - checks for animation event support by checking that either of WebKitAnimationEvent or AnimationEvent exist. Unaffected by removal.

WebKitAnimationEvent.381.txt - uses WebKitAnimationEvent to decide whether to prefix '-webkit' to 'animation-name'/etc. After removal will correctly use the unprefixed version.

WebKitAnimationEvent.006.txt - checks for animation event support by checking that either of WebKitAnimationEvent or AnimationEvent (or MSAnimationEvent!) exist. Unaffected by removal.

WebKitAnimationEvent.528.txt - red herring. Has a variable named 'WebKitAnimationEvent' but doesn't use the interface.

Edge: WebKitAnimationEvent is not supported. AnimationEvent is supported.

Firefox: WebKitAnimationEvent is not supported. AnimationEvent is supported.

Safari: WebKitAnimationEvent is supported. AnimationEvent is supported.

Alternative implementation suggestion for web developers

Developers should use the standardized AnimationEvent interface.

Usage information from UseCounter

See Interoperability and Compatibility Risk above.

Entry on the feature dashboard

https://www.chromestatus.com/feature/6027726842494976

Requesting approval to remove too?

Yes; would like to immediately remove for M71 but otherwise M72.

[Daniel Bratell]

The usage is a bit high. Your analysis did identify a couple of sites that might break or get different behaviour and it's hard to know what usage they represent. There has never (really) been any reason for mobile web developers to not use WebKitAnimationEvent so I think we should at the very least start with a deprecation phase.

With some luck a deprecation phase will make high usage sites (that may have active developers) switch away, hopefully driving the usage down to a level where there is no need to worry.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MadKRqFxbkGRF_chG8RTYTSajbTp0JnoVxyjPDUUPB32YA%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Stephen Mcgruer]

Thanks for the feedback Daniel. I definitely agree there is some risk here, so I would be happy with a deprecation phase if the other API owners agree.

Ping for API owners review.

[Philip Jägenstedt]

Thanks Stephen for the careful analysis.

Two high-level points suggesting low compat risk is that Edge hasn't shipped this, and that 744 total hits in httparchive is not a huge number in a case like this. Given that, the use counter almost certainly doesn't accurately reflect the compat risk, far from it.

With the careful bucketing of results and spot check of the unclassified, it seems like the only case still worth looking at is  'aw_mobile/navigation.js'. Can you get the URLs of the sites in question? (If you used the unjson script they should be at the top of the split files.)

Upon testing those in a real browser, I would not be surprised if the code is unreachable. Or that they are already broken in Edge and Firefox. With either of those outcomes I would still support immediate removal.

(It's not really possible to deprecate this, because window.WebKitAnimationEvent===window.AnimationEvent. Even trying to mark the internal object based on which property was used to access it last wouldn't be robust, and so we'd still fall back to analysis of httparchive.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafQUqWiZeQdxfsCJf4EL91DndKiwqWXDUBfcgExrYYfng%40mail.gmail.com.

[PhistucK]

Deprecation warnings for this would generate many false positives due to window enumeration...

aw_mobile/navigation.js has many if ($j.support.WebKitAnimationEvent), so I am not worried about that one.

(I went over this one - http://www.eternitycenter.com/js/aw_mobile/navigation.js)

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeTYfHcA%2Br%2BUTFuMR%3D%2BoU4a38kC4nOhnKLv3PQMJ-q0Xw%40mail.gmail.com.

[j.j.]

aw_mobile/navigation.js has many if ($j.support.WebKitAnimationEvent), so I am not worried about that one.

(I went over this one - http://www.eternitycenter.com/js/aw_mobile/navigation.js)

... it's a zombie anyways, seems no longer adjunct to any content.

 

[Daniel Bratell]

Good argument against deprecation, and the enumeration also explains the high use counter. Then I'm no longer worried about that one.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BBW-R6WnyYhk9PGVO6bMPHFs8c-gsX_aGxZNR9p%2BiyLA%40mail.gmail.com.

[Stephen Mcgruer]

Phillip - I'm not clear of the status of this I2D, do you still want me to try the investigation you suggested or does phistuck's analysis suffice?

[Philip Jägenstedt]

You said initially that "It is not clear what the usage is; there is branching logic which does different things based on whether WebKitAnimationEvent exists, this may break after removal."

That the branch condition is $j.support.WebKitAnimationEvent is good. It looks like the else branch just doesn't do the animation but skips to the end of it. The script doesn't do anything with "useragent", or use "webkit" in a way that seems like engine sniffing.

Given the small numbers I don't think further analysis or testing is necessary.

LGTM1!

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfkuHuCy6d5FBvYU6mHi3Tqz%2B8-jYU%2BDUC-26g-P9AJaA%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-%3DXdn-9hW5rAUL661ZsVv1J-yEjXm-_To5QNRdhzS7Qg%40mail.gmail.com.