I just got a mail from Chris, who likes my site, and asks the following question:
bq. Just wondering did you ever write something about how you built your site? I could figure it out by studying your CSS, but I thought perhaps you have already made it easy by writing something up about it. Thanks.
His question aligns nicely with the piece I was about to write, so I’m going to answer Chris’ question in some detail before I write my other piece.
h3. Functional minimalism
p(rJust). !/download/171/lc4.jpg (The 1928 Le Corbusier LC4 Chaise Lounge is a truly beautiful piece of furniture)!
These two words provide the most accurate description of why this site looks as it does. If design elements don’t serve a purpose, they shouldn’t be here.
As I’m saying in a comment to this entry, I prefer the 1928 Le Corbusier LC4 Chaise Lounge to the lush Chesterfield furniture.
h3. Markup quality
I don’t let browser bugs or limitations compromise markup. Just because an aging browser doesn’t support a certain feature, you shouldn’t alter and complicate markup.
I do this to obtain _total_ separation of content and presentation. I’m not just talking about not using tables for design, I’m talking about not using @
This means that I won’t use several nested levels of @
h3. Graceful degradation is good for you
Back when I first started _learning_ web authoring around 1996/97, some very insistent people were preaching the Gospel of graceful degradation. This has stuck with me.
Whenever I want to achieve any visual effect that’s impossible to create in, let’s say, Internet Explorer, I try to create it in CSS, using any level of CSS I find neccesary. If the technique degrades gracefully, and the function of the site doesn’t depend on it, I use it.
h3. Minimize hacks
If I want a certain design feature, I always look at how it can be done without invalidating any markup. And if I cannot do it without invalidating either my CSS or my markup, I do a quick evaluation:
* Does the feature degrade gracefully? If so, I do it without hacks.
* If it doesn’t degrade gracefully, I ask myself what benefit the feature gives my visitors. If the benefit isn’t significant, I usually end up not doing it.
* If the benefit is greater than the “cost” of the hack, I try to choose the hack as carefully as humanly possible.
In practice, the combination of these three usually means that I do a hack for Internet Explorer, and place it in a separate stylesheet hidden for other browsers by using conditional comments.
h3. Lynx is King
Lynx is the first browser I check in, and it’s the last browser I check in. If the site is hard to use in Lynx, or the information isn’t easy to find, going back to scratch is the first and best thing to do.
Why? “The single most important user”:http://www.google.com/ is blind. That this user actually is a horde of computers located somewhere in California is irrelevant. It is the single most important user there is.
A positive side effect is that the visually impaired user also gets a far friendlier site.
So, Lynx first, and Lynx last. Lynx is king.
And it doesn’t hurt to check in a browser with image support, but without CSS. If your images serve no purpose then, rip them out and use CSS to show them.
h3. Slow modems still rule
I believe that a significant portion of my users are on broadband, yet: Designing with the 28 800 bps modem in mind improves the experience for broadband users significantly.
It’s better to give the users a fully functional page in 2 seconds, than letting them wait for 10. Visiting a web site should ideally be as quick and easy as flipping the pages of a book.
h3. Final words
I have not covered how I have done and organized my Movable Type templates, as that is a posting far longer than this one.
And before someone flame me for being a markup-zealot: I _know_ that part of the philosophy I’m following here isn’t always a viable option for commercial projects. Other parts of this philosophy, on the other hand, could do some commercial projects some good.
Posted by Arve on 2004-03-08