SVG effects in CSS: Webkit transformations

Amazing news from webkit - they've implemented CSS transformations on their nightly builds!

The web's inability to do transformations - especially rotations - has been an embarrassing failure for years now. I believe the fact that vertical text is not possible has been a major driver behind proprietary "rich internet applications" like Flash.

What's more, the Safari folk seem to have done it properly. They're not relying on SVG foreignobject support, like Firefox; they haven't restricted themselves to simple rotations, instead allowing general affine transformations; and they've started with a simple approach that doesn't affect layout.

Cherry-picking SVG

No doubt they were able to implement this quickly because they've already done it once, in SVG. SVG is great as an image format, and for complicated shapes and paths; but there are surely parts of it that can be brought to the web, via CSS.

For example, how about colour gradients - why not extend the CSS3 color spec to enable the following:

background-color: gradient(red 5%, green 55%, yellow 95%)

which would color the relevant HTML elements with a gradient starting (left to right) with red at an offset of 5%, green at an offset of 55%, etc.

All this would take is to define a new color type in the CSS3 spec, which takes other colors (including opacity via hsla and tbga) as parameters. It could then be used for background colors, border colors, and wherever color is used elsewhere in CSS.

Cherry-picking SVG and putting it in CSS is a great approach. First, it adds style to the web, in a way that properly separates content from presentation. Second, it's tried and tested, so there should be less arguing about the specs. Third, it builds skills and knowledge of key SVG features, building momentum behind the full SVG spec.

Well done, Safari - may the other browser makers learn from your approach.

Blogs and online word processors

What's the difference between Google's Blogger and Google's Docs?

After all, they're both online text editors. They're also both document publishers, though by default Docs doesn't display your document to the world. They both have general document management, including tagging, though Docs also has version control. They both allow collaboration, though Blogger does it through comments and Docs through 'sharing'. They both allow insertion of images and hyperlinks, though in addition Blogger allows videos and Docs allows tables.

None of these differences are major - in fact, I can see most of them being eliminated at some point through general upgrades.

So why do Google have two different applications?

Different uses, same app

They're different because of their history - they're from different cultures. Word processing comes from years of office work, with deeply embedded notions like folders, separate files, and the A4/letter paper size. Blogging comes from an online free-flowing diary format, technically minimalist, constantly added to, and aligned to the computer screen.

That doesn't excuse the basic user interface confusion between the two systems, for example the different ways to edit the underlying HTML. At some point, surely, the solutions must converge.

I can't see that the functionality requirements are different - it's just there are two different uses. Perhaps it's fine they're branded differently, like Proctor & Gamble owning several major washing powder lines to segregate the market.

While blogging tools start to take on advanced word processing features, document tools like Google Docs will improve in "content management" - versioning, publishing, collaboration, tagging, etc.

Surely one tool that can handle both blogging and word processing will emerge soon.

SVG in browsers

A call to arms today from Mark Pilgrim - improving the level of SVG support in Firefox 3, the forthcoming browser. The features in focus include the use of SVG in img elements.

If taken up, this would be excellent news. SVG still has a chance of becoming the most popular vector graphics language, which would be remarkable given the level of investment in Flash, Silverlight and JavaFX.

It would be truly wonderful if SVG became a first class web citizen. There are some important, but technical debates about exactly how it could fit in, especially in the non-XML HTML 5 world. I feel that, much as CSS can be placed inline with HTML but is best positioned in a separate document, the same applies to SVG. That's because of the principle of separation of content from presentation - SVG is fundamentally about presentation (in fact much of SVG, for example rotation, gradients and filters, should be incorporated into CSS so it can be applied to any element).

Regardless of the technical details, it is great to see the defenders of open standards rise to the challenge of proprietary competition, and enable the next cycle of web innovation.