Intent to Deprecate and Remove: WebKitTransitionEvent interface

瀏覽次數:49 次

Stephen Mcgruer

2018年9月10日 下午4:15:102018/9/10

Primary eng (and PM) emails


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.


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

Requesting approval to remove too?

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

Philip Jägenstedt

2018年9月11日 上午11:52:132018/9/11
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

Stephen Mcgruer

2018年9月11日 下午1:41:542018/9/11
> 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%.


$ ls | sort -R | head -n 5

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.

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.

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.

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.

jQuery v1.7.1 (unlikely; multiple js files concat'd and this looks like add-on code)
   * Augments '' with: = (typeof WebKitTransitionEvent == "object");
   * Looks like its a fragment of an old version of jQuery mobile (
   * 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

2018年9月11日 下午2:28:502018/9/11
收件者、Philip Jägenstedt、blink-dev

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
To view this discussion on the web visit

Rick Byers

2018年9月11日 下午6:16:322018/9/11
收件者:Chris Harrelson、、Philip Jägenstedt、blink-dev

Philip Jägenstedt

2018年9月11日 下午6:24:432018/9/11
收件者:Rick Byers、Chris Harrelson、、blink-dev
Thank you Dave, inability to find real breaking cases is very promising, LGTM3!

Philip Jägenstedt

2018年9月11日 下午6:29:252018/9/11
收件者:Rick Byers、Chris Harrelson、、blink-dev
Ahem, thank you Stephen.
0 則新訊息