A couple weeks ago, I posted an entry with the (admittedly sensationalist) title The myth of content and presentation separation. The point of the post was this: Come redesign time, anything other than very minor changes will almost always require changing the markup as well as the CSS. Therefore, fretting over things like the non-semantic class names the Blueprint framework uses is, well, silly at best.
However, I also said this:
Use Web Standards because of the great benefits you get from them. Don’t use Web Standards because Jeffrey Zeldman told you to. Where Web Standards and other best practices don’t provide great benefits, find solutions that do.
I said this, and I absolutely meant it (even if it wasn’t the main point of the article).
In hindsight, it was probably a bad idea to leave this tidbit out there without further clarification. Some people seem to have taken it as an attack on Web Standards. So, I’d like to revisit that comment and clarify what I really meant.
Before we get started, let’s define a few terms, here. First, let’s talk about standards (lowercase). Google shows several definitions of the word, but the one I think best applies here is this:
Agreed principles of protocol. Standards are set by committees working under various trade and international organizations.
Now, what about Web Standards (which I’ll type in uppercase, as a proper noun)? According to Wikipedia:
Web Standards is a general term for the formal standards and other technical specifications that define and describe aspects of the World Wide Web. In recent years, the term has been more frequently associated with the trend of endorsing a set of standardized best practices for building web sites, and a philosophy of web design and development that includes those methods.
With that out of the way, I’ll say this emphatically: I don’t care about standards. Not at all. Not even a little bit. People that know me have worked with me will describe me as practical moreso than pedantic. As such, “standards” will never appear on my priority list. When I’m working on a project, my priorities look something like this:
- Create solutions that solve the client’s stated problems.
- Find ways to achieve the client’s stated goals.
- Find ways to solve problems the client doesn’t even know they have.
- Use tools that are elegant and efficient, and help me produce quality work within the client’s budget and timeframe.
Really, that’s about it. Notably missing from the list is: Use Web Standards (including established best practices).
However, I use Web Standards a lot. 95% of the time, or more. Why? Because, most of the time, they fit right into my fourth stated priority. Using Web Standards is usually the most elegant, fastest, cheapest, and highest quality way to produce a web site. So while I don’t care about standards (those agreed principles of protocol decided by some committee), I do care very much about Web Standards (the tools that help me accomplish my priorities).
And even more to the point, there are times when it makes sense to generally use Web Standards, but in a looser sense in which you may not be overly concerned about a few unencoded ampersands or a few non-semantic class names.
If you are so caught up in doing what’s “right” — meaning what you read in Designing With Web Standards, or on ALA, or on webdesign-l, or even at JeffCroft.com — that you ignore the sorts of priorities I’ve listed, then you are doing your clients a grave disservice.
My point, when I said what I did a couple weeks ago, was that you should evaluate all available tools — including Web Standards — and select the one(s) that are appropriate based on factors like the client’s needs, the project’s budget, and your level of expertise, rather than selecting them based on what some mysterious group of non-web designers say is “right”. If you’re like me, your analysis will jive perfectly with the righteous ravings of your local standardista much of the time. When it doesn’t, remind that standardista that you are the only one who can adequately make these decisions, since you are the one dealing with the client.
And you know what? That’s fine. More power to them. If that’s the world they live in, so be it (I’m not sure how they make any money, but I guess that’s not my business). But keep in mind: their list of priorities would look very different from mine. In the world I live in, there are clients, budgets, deadlines, resource limitations, and bosses to answer to. My list of priorities reflects that.
And that’s why I said: Use Web Standards because of the great benefits you get from them, not because Jeffrey Zeldman told you to. Web Standards are a means to an end, not the end itself. In other words, if you’re a working web designer, put serving your client’s needs ahead of impressing your pedantic standardista friends.