Intent to Deprecate and Remove: WebKitTransitionEvent interface

[Stephen Mcgruer]

Primary eng (and PM) emails

smcg...@chromium.org

Summary

Deprecate and remove WebKitTransitionEvent interface. WebKitTransitionEvent is the prefixed version of TransitionEvent. TransitionEvent is the event interface used for events relating to CSS Transitions (e.g. transitionstart).

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

> window.WebKitTransitionEvent

ƒ TransitionEvent() { [native code] }

The only remaining way a web developer can interact with WebKitTransitionEvent 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

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

Interoperability and Compatibility Risk

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

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

• 2607 results (>50% of total) from an outdated (2012) version of jQuery Mobile. The reference is used as part of a test to detect whether 'cssTransitions' are supported, however the test still passes without it (as Chrome passes the same fallback check that Firefox/etc would).
• 739 results (~14% of total) which are believed to also be from jQuery mobile, but didn't match the exact results of the above. Sampling shows that they appear to just be minified in different ways.
• 529 results (~10% of total) from an unknown library called 'sca.17.4.36.js'. This appears to be fingerprinting code, as it builds a giant bitstring with many, many different browser properties.
• 216 results (~5% of total) from various scripts (different names, same content) from blueconic.net. Appears to be fingerprinting.
  
• The remaining 20% are split between the following libraries, which have not been closely analyzed: celtra_web_js (123 hits), lightview_3.4.0 (122 hits), google_gtm (51 hits), flicksimple (24 hits), and as-yet-unsorted (592 hits).

Edge: WebKitTransitionEvent is not supported. TransitionEvent is supported.

Firefox: WebKitTransitionEvent is not supported. TransitionEvent is supported.

Safari: WebKitTransitionEvent is supported. TransitionEvent is supported.

Alternative implementation suggestion for web developers

Developers should use the standardized TransitionEvent interface.

Usage information from UseCounter

See Interoperability and Compatibility Risk above.

Entry on the feature dashboard

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

Requesting approval to remove too?

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

[Philip Jägenstedt]

Thanks for the detailed compat analysis, Stephen.

On the compat risk, I think the strongest reason why this is likely to work out is that Edge have not found themselves forced to add these aliases, and they have added lots of other webkit-prefixed things as needed for web compat.

We have seen sca and blueconic show up many times myself, they are indeed trying to collect fingerprinting bits, and previous removals have worked out.

Stephen, of the remaining 20%, could you take a random sample of 5 and see if they would be affected? If we pretend that use counter numbers are proportional to hits in httparchive, the remaining usage could still represent 0.6%.

I do think the compat question will be settled ultimately by trying to ship. I don't think we should have a deprecation period for this, because the deprecation message would be at least 80% unhelpful, and if we're right and there is no compat risk much closer to 100% unhelpful.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MacsARnZXR9xBfK_C5f5-aFXESdUotkgZkB-ERaU53Z1YQ%40mail.gmail.com.

[Stephen Mcgruer]

> Stephen, of the remaining 20%, could you take a random sample of 5 and see if they would be affected? If we pretend that use counter numbers are proportional to hits in httparchive, the remaining usage could still represent 0.6%.

Done.

$ ls | sort -R | head -n 5

WebKitTransitionEvent.1931.txt

WebKitTransitionEvent.3592.txt

WebKitTransitionEvent.4375.txt

WebKitTransitionEvent.4940.txt

WebKitTransitionEvent.1901.txt

WebKitTransitionEvent.1931.txt

jQuery v1.11.0 (unlikely; multiple js files concat'd and this looks like add-on code).

  * Checks if TransitionEvent doesnt exist and WebKitTransitionEvent does. If so, remaps transitionend --> webkitTransitionEnd. Unaffected by deprecation.

WebKitTransitionEvent.3592.txt

lightview 3.5.1 (missed by previous bucketing for lightview)

  * Determines css.transition support by running 'document.createEvent' across ["WebKitTransitionEvent", "TransitionEvent", "OTransitionEvent"]. Unaffected by deprecation.

WebKitTransitionEvent.4375.txt

Unable to determine source.

  * Unable to break code down. Massive string with a strange mix of properties (refreshPreviousNext, plugins, x1, ...), '|' delimited. I suspect fingerprinting code.

WebKitTransitionEvent.4940.txt

Supposedly 'Tipped - The jQuery Tooltip - v2.4.7', but WebKitTransitionEvent code looks pasted on at the end

   * Looks to be same code as WebKitTransitionEvent.4375.txt, may have different properties present in the massive string.

WebKitTransitionEvent.1901.txt

jQuery v1.7.1 (unlikely; multiple js files concat'd and this looks like add-on code)

   * Augments 'jQuery.support' with: jQuery.support.WebKitAnimationEvent = (typeof WebKitTransitionEvent == "object");

   * Looks like its a fragment of an old version of jQuery mobile (https://forum.jquery.com/viewFile.do?fileId=14737000001597168&forumGroupId=14737000000003003)

   * This would break with the change (but since I'd also like to remove WebKitAnimationEvent I'm not too sad about that... :D).

[Chris Harrelson]

LGTM1

Thanks for doing the research! This level of compat risk sounds low enough to me to unblock this intent.

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/CADY3MaciokucEdc8nnFiERDkN2N8444RX6932YFB8O-Mx2hY-Q%40mail.gmail.com.

[Rick Byers]

Great analysis, thanks! LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-CFSY6VQ1YunkXH5n5CBQq3%3DYLCKSiEj0q7UFN%3Dr0dNQ%40mail.gmail.com.

[Philip Jägenstedt]

Thank you Dave, inability to find real breaking cases is very promising, LGTM3!

[Philip Jägenstedt]

Ahem, thank you Stephen.