The Front End

I’m sure, like me, you’ve come across sites which seem reasonably well designed but where the font looks all wonky and manky, as if it got rendered at a different size and scaled down using a nearest-neighbour transformation *. I came across one today and decided to get to the bottom of it. (For the record, it was for this interesting-sounding SEO tool.)

The cause? Not the use of <font> tags — though what the hell are they doing there? — per se, but their insistence on face="Lucida Sans". Strip them out, or bung in an accepted web font like Arial, and the lumpiness disappears.

Shame, really, ’cause Lucida Sans is a great font, but it clearly doesn’t scale well, or at least not the version installed with XP on my PC. (And no, it’s not the browser. IE6 & 7 make as much of a mess of it as Firefox does.)

Makes you wonder why the designer thought it worked. The stylesheet (yep — he or she did know about CSS) specifies an unusual body font size of 78.5% and if I could be bothered I reckon I could use this to figure out their monitor resolution. It must have been a lot of dots per inch, as there are certain high magnifications where the text looks as Charles Bigelow intended. 140% in IE7, for example.

So add this to the usual admonishments about specifying font sizes and the like: don’t be tempted to stray from standard web fonts or, SEO company or not, you may drive away visitors with unreadable text.

*My best guess is that this is exactly what’s going on.

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.