Anyone running an older browser?

[Shikkediel]

I’m kinda curious if the following is bullet proof or not… testing for the transitionend event by checking 'TransitionEvent' in window.

It seems to work well for modern desktop browsers and IE emulation (which discerns IE9 from IE10) but I’d really like to know if it’ll also return correctly with older browser versions.

My suspicion is that is should work well. Although TransitionEvent is mostly not yet usable as a constructor, the now deprecated predecessor sub function has been present from the start:

TransitionEvent.initTransitionEvent()

So anyone still running an old beastie? Or can tell me where the thought process might be wrong…

Modern
Deprecated

Dutch Mozilla page shows both (in English)

Maybe a test page can be handy but I’ll go there in case of a positive response. Running console.log('TransitionEvent' in window) in the console could also be a temporary option there.

Most relevant are probably the browsers that still needed a prefix for the transitionend event. Which for ease I will assume to coincide with the needed prefixes for transition:

http://caniuse.com/#feat=css-transitions

Edit:

Support listed is for transition properties as well as the transitionend event.

So I guess the assumption was correct.

[Shikkediel]

In addition, how (if at all) will I be able to find the possible prefix of the event through this constructor?

When impossible, there’s always the way of multiple listeners of course. Just looking for the leanest code…

Demo

Edit – I’m a bit wiser already. Apparently the events themselves are also part of the window object so 'ontransitionend' in window will do the same check. I see in Opera a webkit prefixed event is also still present.

So why then does creating a temporary element and reading it’s CSS properties seem to be the accepted way of feature tesing this event listener…

davidwalsh.name/css-animation-callback
stackoverflow.com/a/9090128/3168107

[Shikkediel]

In addition, how (if at all) will I be able to find the possible prefix of the event through this constructor?

I suppose that’s a Catch-22, you can’t take any info from it until it is fired. Makes one think how do events actually work? As far as I get it, the browser “detects” changes then sends the info to window which creates an event and usually then starts listening for it. But not in all cases:

Apparently the events themselves are also part of the window object so ‘ontransitionend’ in window will do the same check.

That seems to only be true with Webkit related browsers. Firefox and IE don’t have this global event. So that’s not gonna help a lot.

Trickier than I thought, hence likely the creation of that dirty extra element in the accepted feature test…

[Shikkediel]

I guess checking for TransitionEvent in window can be a handy little helper but never a stand alone feature test. Not for a bit of browser sniffing anyway. Is my current level of understanding JS…

Simply doing a console.log(window) is quite interesting and opens a whole world to explore (for someone with nerdish tendencies anyway). It also shows why one shouldn’t clutter the global scope more than it has been already by creating additional variables and functions in it.

How very convenient it would be to be able to run several (older) versions of the browser ensemble.

By the way, according to the Mozilla spec only Firefox itself is using the new approach. But none of the other modern browser showed the old event constructor, so they might’ve been moving ahead of what the documentation states.

[Shikkediel]

Let me just add that checking for the presence of TransitionEvent looks to be a perfectly lean feature test for transition capability in general. Although for the specifics on the prefix of the event listener one would still have to access some element style (not by necessarily creating a new element though), if you want to decide in a script whether to use CSS transition by adding a class or creating the animation with jQuery for example this test could very well serve it’s purpose.

I’m still wondering if it’ll return true with some of the older browsers that were using the now deprecated constructor…

[Shikkediel]

Bummer, doesn’t work on Android 2.3 and that definitely has the event handlers for transitions.

No clue how to inspect the window object wit that phone since it doesn’t have a console. And the “greyed out” constructor functions in the desktop console do not show when you iterate over them and try to append them as text… you only get to see the “active” items, the functions you can use as site developer.

As interesting as this was, probably a dead end. :-/

Edit – oh my, don’t throw it away yet. This might be one for the long term study. Just noticed 'WebKitTransitionEvent' in window does return true on the good old Android.

I’ll stop blogging about it though. At least until real further results. Replies welcome nonetheless.

But I will be adding a simple test page, just in case…

---

Here it is:

http://ataredo.com/external/demo/transition-event/

[Shikkediel]

Lemme wrap this up… yes, it’s usable. I have also found comparable snippets on the net with the same approach. Many with doubtful camelcasing for the constructor function as well as the event listeners though. You know there’s not a lot of info around when your Google search shows two meager results.

:-/

Firefox and MS are straightforward – presence of the TransitionEvent constructor object in windowmeans transition support. Then there’s the older Webkit related browser (Android as well), having their own prefixed constructor. So if the plain one isn’t there, we’ll see if the prefixed version is. Opera is a tricky one but Webkit compliance was introduced with 12.5 so easiest is to leave out the versions down to 10.5 where transition capability was introduced and not check for the O prefix.

Coming down to this:

var event = 'TransitionEvent',
listener = (function() {

  if (event in window) return 'transitionend';
  else if ('WebKit' + event in window) return 'webkitTransitionEnd';
})();

The variable listener will then have the string value of the appropriate transitionend event. And can be used like this:

element.addEventListener(listener, function() {

// Do something when transition ends

});

Shorthand code:

var event = 'TransitionEvent', listener = event in window ? 'transitionend' : 'WebKit' + event in window ? 'webkitTransitionEnd' : '';

My brother’s still running Opera 11 on an XP machine. Strangely enough the test page (unfortunately offline at the moment because of maintenance) did not return the expected result there. Another reason to not have incorporated that early browser here.

Besides the fact that the event was introduced as oTransitionEnd in 10.5 and changed into otransitionend in 11.6 (according to the Presto pages, not with 12 like the Mozilla doc states), only to get WebKit compliance in 12.5 and unprefixed support with 12.10. What a mess. Slightly unclear as well if the event constructor went from OTransitionEvent to oTransitionEvent…

[Shikkediel]

Side note… to support all browser versions complying with transition capability checked through the TransitionEvent method, these CSS prefixes would be needed:

.capable {
  -moz-transition: ...
  -webkit-transition: ...
  transition: ...
}

Firefox is the exception when it comes to the overlap, some early versions can be checked with the presence of TransitionEvent and also fire a plain event without prefix – but the CSS still needs it.

Hosting trouble seems to be mostly over so the page in the post above is working again. Should anyone still have an old browser at hand, I’m very curious what Opera 10.5-12 will report on an OS other than XP.

By the way, according to the Mozilla spec only Firefox itself is using the new approach. But none of the other modern browser showed the old event constructor, so they might’ve been moving ahead of what the documentation states.

That was before I noticed current Opera and Chrome are still using both TransitionEvent and WebKitTransitionEvent so it’s more likely they’re somewhere in between.

[Author]

Posts