After my first teaser image, quite a few wondered why I’d bring out a version featuring CSS Transforms for Internet Explorer out instead. The reason why I now completely discontinued the CSS Transforms work for Firefox is that CSS Transforms are being shipped most likely along with the 3.1 release.

However, I think the two approaches were still interesting, so I’m discussing them with you:

The Canvas approach

This was my initial attempt to bring CSS Transforms to Firefox. Since there was no hack like using the Matrix Filter in IE, I had to do it the hard way. I knew that rendering web content to into a canvas was already supported by Firefox long ago but was then taken out due to security issues. So I had to take the long road and actually build my own limited rendering engine in Canvas (as some pointed out, of course not featuring things like inputs, buttons, everything natively styled by the OS).

Here’s how the logical implementation looked like:

  1. Find all instances of -webkit-transform
  2. For every found element:
  3. Create a new <canvas> element at the exact same position as the original, with the same constrains
  4. Rotate/modify/translate the whole canvas by the values found in the transform functions
  5. Literally draw borders, background and text (using FF3’s new text API for canvas) for the original item into the canvas and for all sub items
  6. Recompute the new constrains of the element and reset the constrains of the canvas

Although insanely difficult, it was working better than I initially thought, and I was able to create a DIV element with all kinds of sub nodes and rotate it with full speed in a nice animation.

The SVG approach

That’s when I found out about the foreignObject in SVG – since I never really played with SVG, it was completely new to me. The foreignObject basically is able to display namespaced XML, including HTML in an SVG canvas.

The fun thing here is that I immediately sensed that it was much more promising, because the CSS Transforms API is almost exactly copied from the SVG API, and if I could get the initial work done, I thought to myself, mapping it would be fairly easy.

Then I found about the limitations about SVG. For example, that it’s not possible to include inline SVG into an HTML page without serving the Content-Type as XHTML. Okay, this was a show blocker for my plugin, because I couldn’t possibly force people to use XHTML whenever they wanted to use CSS Transforms..

However, I did actually find a way to display inline SVG in HTML after many hours of research, and this is the implementation I came up with:

  1. Find all instances of -webkit-transform
  2. For each element,
  3. Serialize the whole node (outerHML) into a string (without positioning data in the style attribute)
  4. Wrap it with a prepared SVG XML Header
  5. Also insert the transform value as <g transform=’..’>
  6. Encode the whole string to base64
  7. Create a new embed element with the base64 String as data source, and render it to the page (with the position data from the original node on the actual <embed>)

If I would have continued with the development of the plugin, than definitely using the SVG approach. It’s pretty slow to do transformations on a foreignObject in Firefox 3, but you don’t loose the OS styles, and it’s so much easier since you don’t have to port over the CSS Transform API to something different.

See you soon with more exciting projects!

Reply with a tweet or leave a Webmention. Both will appear here.