Building Games with CSS3 - HTML5 Mobile Game Development - page 222

Listing 12-3: Checking for transition support
(function() {
function transitionBuilder(attribute,prefix){
return function(dom,property,sec,easing) {
easing = easing || "";
if(property == 'transform') {
property = prefix + property;
}
sec = sec || "1s";
dom.style[attribute] = property + " " + sec + " " + easing;
};
}
// Dummy method
function fallbackTransition() { }
var dummyStyle = $("<div>")[0].style;
var transitionMethods = ['transition',
'webkitTransition',
'MozTransition',
'msTransition' ];
var prefixNames = [ '', '-webkit-', '-moz-', '-ms-' ];
for(var i=0;i<transitionMethods.length;i++) {
var transitionName = transitionMethods[i];
var prefixName = prefixNames[i];
if(!_.isUndefined(dummyStyle[transitionName])) {
Q.transitionDOM = transitionBuilder(transitionName,prefixName);
break;
}
}
Q.transitionDOM = Q.transitionDOM || fallbackTransition;
})();
This block follows the same pattern as the code in the previous section except its goal is to create a method
that lets the developer add a transition on a property in a consistent manner. In this case, if there isn't built-in
support, the fallback is to just do nothing. The game still runs as expected, but all transitions are instant instead
of animated.
Implementing a DOM Sprite
Next up is the DOM equivalent of the Canvas Sprite class. This class actually extends the base Q.Sprite
class. (So the Quintus.DOM module must be loaded after the Quintus.Sprites module.)
As mentioned previously, the primary difference between a DOM and Canvas sprite is that a DOM sprite
doesn't need to worry about drawing itself, but it does need to make sure it keeps the properties of the DOM
element in sync with itself.
Add the code in Listing 12-4 to the bottom of quintus_dom.js before the final closing curly-brace.
Listing 12-4: The DOMSprite class