Although the current code does indeed only use the `scale` transform, for quite a while I was also employing the `translate` transform, and the effort to support multiple transforms highlights a rather tricky aspect of CSS transforms that I think recommends the current implementation as the least error-prone approach.

Here's what's tricky about CSS transforms. (In the examples below I'm omitting the vendor prefixes for brevity and clarity.) The [official way](http://dev.w3.org/csswg/css-transforms/#propdef-transform) to define multiple transform in a CSS style rule looks like the following:

    .selector {
        transform: scale(2.0) translateX(10px) translateY(20px);
    }

For convenience and readability, browsers also support the following syntax as equivalent:


    .selector {
        transform: scale(2.0);
        transform: translateX(10px);
        transform: translateY(20px);
    }

The second format is quite common and it is one developers researching CSS transforms are perhaps most likely to see. Unfortunately, that may lead them to expect the following JavaScript code to function identically to the the CSS rules above:

    $(.selector).css('transform', 'scale(2.0)');
    $(.selector).css('transform', 'translateX(10px)');
    $(.selector).css('transform', 'translateY(20px)');

In fact, the code does not function as intended because successive applications of the CSS `transform` property, **_when applied via JavaScript_** are not additive but, instead, replace previously applied values. So, in the code fragment above, the **_only_** transform that would be applied to the selector is the final `translateY()`. In effect, this means that you should only call `$().css('transform',...)` once for any given element. (Unless, of course, you intend to overwrite existing values.) The correct way to implement the above code fragment is

    $(.selector).css('transform', 'scale(2.0) translateX(10px) translateY(20px)');

Of course, once we take into account the vendor prefixes, it becomes desirable to encapsulate the application of CSS transforms into JavaScript functions. Such encapsulation isolates a particularly unstable part of the HTML API into a single location. Given the behavior above, however, having unique functions for individual transforms (e.g. one function for `scale` and a separate function for `translateX`, etc.) would not be manageable. If there were a `cssScaleTransform()` and a `cssTranslateTransform()` helper function, there would also have to be a `cssScaleAndTranslateTransform()` function to support simultaneous application of both properties. Even if it were possible to manage the ensuing permutations, the temptation for a developer unfamiliar with the subtleties to simply call `Scale()` and then call `Translate()` might simply be too great to resist.

The recommendation holds even though the current code is only using a single transform. There is no certainly that a single transform will always be sufficient. (Pending further QA testing, I'm not willing to rule out the necessity of the `translate` transform as well as `scale`.) And it may well be the case that a developer could "copy and paste" the implementation into another module that did require multiple transforms. Because the current implementation emphasizes the fact that multiple transforms must be applied simultaneously rather then serially, it is most likely to prevent the introduction of errors in future code.