CSS3

The Webkit team have certainly been busy recently; since we mentioned the introduction of web fonts, they’ve also implemented transformations and animations.

Transformations, via the -webkit-transform property, allow you to scale, rotate and skew block elements; reader Ain Tohvri has put together an impressive test suite. At the moment this property doesn’t affect layout, so behaves more like a relatively positioned element.

Animation, which uses the -webkit-transition family of properties, allows you to set timings for fades, rotation, expansion, collapses, and more. They work in the same way as many current JavaScript libraries.

I’m in two minds about this; while it’s always welcome to see more innovation from browser manufacturers, I can’t help but think that they’re focussing their energies in the wrong direction. As I mentioned above, all of the above effects can be replicated with JavaScript libraries, and I don’t think that CSS should be used for controlling behaviour so explicitly. Users who don’t like to see animated pages currently have the option of disabling scripts, but they won’t have the option of disabling CSS in the same way.

Also, IMHO, there are a more pressing areas of CSS that need investigating; the Advanced Layout or Grid Layout modules are more important to the future of CSS than animations and transformations.

On the positive side, the Webkit team have promised to release technical documents which explain the proposed spec in detail.

If these new features float your boat, you can test them out by downloading the latest Webkit nightlies.

The latest Webkit builds now support an open implementation of the @font-face rule, which we wrote about some time ago. Recent articles by Håkon Wium Lie had indicated that Opera might be first to market with this, but the Webkit team seem to have beaten them to it.

In short, @font-face allows you to download fonts to the visitor’s browser, meaning you can use any licensed font to display your pages. An example of use would be:

@font-face {
font-family: 'The New Font';
src: url('http://www.example.net/newfont/');
}

It’s a step forward for the web, and I’m delighted it’s here. Congratulations to the Webkit team, and here’s hoping that Opera push forward with their plans to implement it too. It seems like Firefox 3 won’t support this rule, so late 2008 may be the earliest we see this in Mozilla browsers.

As for Internet Explorer, they’ve actually implemented @font-face since version 4! However, it only works with their proprietary font format, .eot, and never took off. I wonder if they will reimplement it with Open- or True-Type fonts now.

@font-face isn’t actually new in CSS 3, it’s been around since CSS 2. However, as it’s never been properly introduced I think it’s okay to include it here!

CSS3 now has a new proposal for laying out websites, with the release of the first working draft of the grid positioning module. The new module makes it easier to define layouts using typographic grids (see Khoi Vinh’s website for a good introduction).

Used in conjunction with the multi-column layout module, you can use the new gr measurement unit to define objects that span multiple columns:

body { columns:3; column-gap:0.5in; }
img { float:page top right; width:3gr; }

Or, using the new grid-columns and grid-rows declarations, you could quickly divide up a page for layout purposes:

body { grid-columns: * * (0.5in * *)[2];
grid-rows: 20% *;
columns:3; column-gap:0.5in; }

I’ve only had the chance for a cursory look at this so far, but it strikes me that it’s not quite as intuitive as it could be, although I need to have a proper look before I can put my finger on exactly why. However, it’s a nice attempt by the W3 to solve the problem of print-style layouts, and after further revision I’m sure it will be a welcome addition.

Since the move away from tables to CSS-based layouts, lists have become more important in producing semantic markup; in Andy Clarke’s Transcending CSS, he seems at times to be on the verge of saying all content can be marked up with lists!

Yet the basic list itself is let down by the range of markers available; for unordered lists you have disc, circle or square, or images which are implemented so differently across browsers that it’s better not to use them. Perhaps most annoying of all, you can’t have the glyph be a different colour from the content without extra markup:

<li><span>Lorem ipsum</span></li>

That could be set to change with the proposed new lists module which allows a much wider range of glyphs, markers and counters and, more notably, the ability to style them with the ::marker pseudo-element. In a nutshell, this allows you to treat the list-style-type as a separate entity and style it accordingly.

The working draft doesn’t specify exactly what declarations you’ll be able to apply, although it does mention borders, margin, and padding so it’s not a great stretch to imagine that you could add colour and font styles to that also - meaning lists could be set to become a lot more decorative:

li::marker {
background-color: #fff;
border: 2px dotted #f00;
color: #f00;
font-size: 2em;
height: 4em;
text-align: center;
width: 4em;
}

Do I have to include the usual disclaimer? This is still only a working draft of a proposal (and a low priority one at that), and browser support currently stands at nil.

I was reading Veerle’s blog today; the excellent article A CSS styled table version 2, to be precise. All good, practical stuff, and well-presented as usual. But what stood out for me was the technique to stripe the table rows: either through classes, or Javascript.

Of course, both of those are valid techniques; but really, neither should be. It’s pretty easy to forget, when we see how far CSS-based design has come in the last few years, just how reliant on workarounds and tricks we are in order to perform what should be basic functions.

Presented below are some of those workarounds that I’d love to see consigned to the dustbin of history; not because they are bad - on the contrary, they are extremely inventive - but because CSS 3 should allow the effects to be replicated without the extra mark-up, script or code.

Tiger-striping on table rows

Whether done with background images, DOM scripting or just adding classes to the markup, none of the techniques are as easy as using the nth-child pseudo-class:

tr:nth-child(odd) { color: blue; }

‘Sliding Doors’

Requires no extra mark-up but a lot of CSS jiggery-pokery, most of which could be avoided with multiple background images:

li {
background: url('image0.png') no-repeat left top,
 url('image1.png') no-repeat right top;
}

Rounded corners

Which do you prefer: multiple lines of Javascript? Or a single line of CSS?

div { border-radius: 1.5em; }

Drop shadows

Even the simplest solutions seem to rely on an extra image and plenty of CSS tweaks. CSS 3 resolves it with one declaration:

img { box-shadow: 10px 10px 5px; }

Of course, the problem is that perennial one: lack of support. No modern browser currently supports all of the examples shown above, and it will be many years before we can stop using the workarounds altogether. But I do look forward to the time when they become a secondary consideration - and to what extensive use of the new declarations reveals in terms of creating new workarounds to future problems.