catering to the impatient

lean html and css

First off, there were three comments (by Terrence Wood, Denis Sokolov and Jordan Clark) I received on my blog which all brought up the speed/size problem. I wasn't really surprised to receive these comments as they were all given in a series of articles that speaks in favor of leaner css at the expense of more convoluted html, which is not a popular idea at all.

I was surprised at their arguments though, as they were not about the purity of html and semantics, but about file sizes and speed gains. Now I understand that extra structural elements increase DOM processing, page loads and traffic, but I always figured these additions were to be neglected. I still think so, unless I see some proof that tells me otherwise. I understand that you gain a little speed in trimming your html to perfection (as it needs to be reloaded for each new page, as opposed to css which is often cashed), but I fail to believe it will have any important impact on the user experience.

What worries me more is the way most people are looking at css. It's the garbage can of web development. A no man's land where no official rules apply and which often functions as a kind of black box. You throw it on your html and if the design comes out okay you've done a good job. And the smaller the file, the better. There is little to no talk about how to organize your css, either physically or (more importantly) on a conceptual level.

There is no care or worry about writing flexible and maintainable css, especially not when it makes a file bigger or even worse, has an impact on the html. I find that a sad thing, especially as there's not else to do with css at this time. Now is the time we should be worrying about how to improve our css files, how to make them easier to work with and how to protect them from becoming a complete mess when design changes are needed. Instead, we are talking about shaving of the final semi-colon to lose a couple of bytes.

invalidating html

What boggled and surprised me even more was an article written by Jens Meiert on invalidating html in order to save bytes and gain speed (as in lesser traffic = faster). Now I respect Meiert's articles on web-related issues a lot and in his article he does elaborate that this is an experts technique, but I really fail to see his point.

Meiert talks about shaving of quotation marks and the like, which will obviously save you a few bytes but will invalidate your html. Still, browsers will render your pages okay. But opposed to the comments above, I can actually think of ways where this might even slow down the rendering of a page (in the long term). Currently, browsers use draconian parsers to parse the html. This means that when they encounter syntax errors in the code, they will try to fix it to their best knowledge, allowing them to still render the code okay.

This sounds nice, but working like this doesn't make the parsers any easier or faster. Invalidating your code will only further the need for this kind of parsing, which isn't helping out web development as a whole at all. I can see the gain on a small scale, but from a long-term view it makes no sense to me whatsoever. I can only hope this won't be becoming a real trend.

prove me wrong

I'll be honest and admit that I know little about parsing speed and DOM processing. But I have some common sense and when I apply it to the arguments given I can hardly imagine that we're really gaining something significant here, while at the same time we could be making much more important progress elsewhere.

But prove me wrong, I'm interested in seeing stats and figures on the effect of extra structural mark-up, superfluous semi-colons and quotation marks and unnecessary classes. Maybe then I can change my mind about things.