Monday, September 15th, 2008

CSS Transforms: First WebKit, now Gecko too!

Category: Browsers, CSS

We discussed the WebKit CSS transforms that allow you to scale, transform, skew, and do matrix work through simple CSS.

Mozilla has stepped up and Keith Schwarz posted on CSS transform support in Firefox thanks to the new -moz-transform:

  1. -moz-transform: translate(100px, 200px); /* Move right 100 pixels, down 200 pixels */
  3. -moz-transform: translate(30px); /* Move down and right 30 pixels */
  5. -moz-transform: translate(50%, 50%); /* Move down and right by 50% of the size of the element. */

This function simply moves elements around by the specified offset. For example, a text element with -moz-transform: translate(100px); will appear 100 pixels downward and to the right of where it normally would have been displayed. Of course, there are more functions than just translate. For example, there’s rotate, which lets you rotate an element by a specified number of degrees; scale, which scales elements by arbitrary dimensions along each axis; skew, which performs skews along the X and Y axes; and matrix, for arbitrary matrix transformations. There are also simple versions of these like skewx and scaley which allow for simpler syntax in some cases.

It will be interesting to see what uses developers find for CSS transforms. Much of the functionality once reserved for plugins can now be directly integrated into CSS and Javascript, which hopefully will help web developers create more graphically exciting pages. We also look forward to rapid standardization of this property now that there are two implementations.

Posted by Dion Almaer at 9:55 am

3.9 rating from 29 votes


Comments feed TrackBack URI

The title should be: First IE, then nobody, then WebKit, then Gecko as IE offered Matrix transformations in IE5.5, released july 2000.

That doesn’t mean I’m not happy with current developments.

But. Where’s the z-axis in Gecko? No 3D rotations/translations yet?

Comment by Lon42 — September 15, 2008

Lon42, very good reminder on IE’s (oh, that old new kind-of-browser) original “missing” implementation…
BTW: It’s getting really fun with all “standardization” efforts. Imagine CSS files full of:
-moz-transform: translate(30px);
-ms-transform: translate(30px);
-webkit-transform: translate(30px);
-safari-transform: translate(30px);
Wish we had more browsers willing to participate the rush ;)

Comment by sergeyilinsky — September 15, 2008

Nice, I’ll experiment with them to learn the tricks but I think I’m not using them in my projects until browser vendors remove the -moz/-webkit prefixes from the declarations. I don’t want to use both -moz-transform and -webkit-transform in my CSS files, maybe with even different arguments and results.

Gecko 1.9 alpha is using the video tag and not a moz-video one, even if HTML 5 is still a draft recommendation. Why can’t they do the same for CSS transforms, which are in draft stage as well?

The same happened with border-radius weeks ago.

Comment by pmontrasio — September 15, 2008

Hope Mozilla unveils CSS Transitions at the same time as Transforms.

IE’s matrix filters are a pain to use. Try, for example, applying a rotation transform to an alpha-transparent PNG. IE’s filters aren’t integrated deeply enough into the rendering engine.

Comment by westonruter — September 15, 2008

The prefixes are there to avoid compatibility problems if the finished spec is different from the current implementation. They are a pain, but having suffered the effects of “padding” not working equally across browsers, I guess it’s not that bad.

I can’t wait for the prefix to dissapear, thought, as it will mean a standard has been reached and the properties can be used safely.

Comment by Salva — September 15, 2008

This is very good!
CSS3 – to the all browsers!

Comment by 115516 — September 15, 2008

@Salva: I understand the reason for prefixes, but it’s a pain and I don’t understand this double standard between draft html tags and draft css declarations.

This draft thing is a nonsense because different browsers keep behaving differently even on standardized things like paddings, borders, margins and tables. I really don’t see many differences between draft standards and having to deal with IE6/7, FF2/3, Opera, Safari and now Chrome.

A solution would be implement both the browser specific declaration and the standard one (i.e. both -moz-transform and transform): developers that want to play safe will use the former, developers who want to take risks will use the latter. Furthermore, there aren’t more risks in the latter approach than in dealing with the usual incompatibilities between browsers: test a lot, fix the layout and the css, iterate.

Comment by pmontrasio — September 16, 2008

Leave a comment

You must be logged in to post a comment.