The IE blog has had a couple posts recently about new JavaScript APIs that are vendor prefixed: http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficie... http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficie... Here's one of their code examples: ----8<---- // Future-proof: when feature is fully standardized if (window.requestAnimationFrame) window.requestAnimationFrame(draw); // IE implementation else if (window.msRequestAnimationFrame) window.msRequestAnimationFrame(draw); // Firefox implementation else if (window.mozRequestAnimationFrame) window.mozRequestAnimationFrame(draw); // Chrome implementation else if (window.webkitRequestAnimationFrame) window.webkitRequestAnimationFrame(draw); // Other browsers that do not yet support feature else setTimeout(draw, PERIOD); ---->8---- There are a couple things to notice: 1) The requestAnimationFrame API has a vendor prefix in all of these implementations, making this code ugly. 2) The vendor prefix isn't buying us anything because this code assumes that the final, non-prefixed version of the API will work the same way that the vendor prefixed version works! If web developers are going to assume that future, non-prefixed versions of the APIs work the same way as current prefixed versions of the APIs anyway, we shouldn't bother with prefixed versions because we're already locked in to the current behavior, even without the prefix. Adam