The Front End

Someone recently posted on the css-d list (a useful place to learn more about practical CSS) a very ugly hack which proudly announced at the end “this hack is valid CSS3″. Well, great. Does that mean that whatever flaw in the target browser (in this case Safari) the hack was used to work around will bring other browsers to their knees when they catch up in CSS support? Not a great approach to web site building.

I am not anti-hack. Recently I resorted to an amazing filter: hack to get around an inheritance bug in IE6, and I use * html in pretty much every stylesheet I write. But normally I am compensating for some major lack of support in the still-unfortunately-widespread IE6 that other contemporary browsers have (eg no min-height). I think hacking for leading-edge browsers is a bad idea, and try to confine myself to hacks that can do no harm in the future (I don’t use the underscore hack, but it’s a safe one, as it’s unlikely new browsers will suddenly start supporting it.)

And as for “valid CSS” – I could care less. zoom:? filter:? Ok, if it works. Valid HTML - yes, please. That’s future-proofing. But isn’t CSS where we shunt all the complexity and ugliness that used to be in the markup? One day there may be an elegant and easy-to-understand layout language, but sadly CSS ain’t it.

In my view, as developers we are custodians of the information entrusted to us. In trying to make it appear on screen as intended we should add as little cruft to the markup as possible to achieve the desired look and feel. CSS and Javascript are tools to add visual appeal and functionality to the basic information. These need to be future-proofed too, of course, but we must accept that they are of secondary importance and some day they may be superceded.

Aiming for valid CSS is fine, and won’t it be nice when it’s all we need? But we mustn’t fool ourselves into thinking that if it validates we can’t have done anything wrong.