Standards – Just One Part of a Sensible Design

It’s been quite a drag, but hey, we got there!

Slowly but steadily, people seem to have recognised that Web development is not about putting together things we don’t really know in a fashion we’re unsure of, then invoicing the client for the job before it all blows up.

Annoyingly for some, the people who pay us have also started to ask for accessibility and validation and other things we didn’t have to deal with in the bad old days of wild, wild Web development.

No sweat, we can handle that. After all, we wanted standards recognized and we evangelised long enough to people on mailing lists, forums and chat channels. Now, let’s bask in our glory, get comfy on our laurels and look down on the unwashed rabble that still use <font> and write their tags in uppercase… or should we?

Web Standards Include Boring Old Markup

Using Web standards is the right thing to do, but, as with any recommendation, there’s no point following them off a cliff. New developers tend to over-react and take things a little too seriously. There is nothing evil about using a table for tabular data, for example. Many’s the time I’ve seen newbie Web standards champions turn shyly to mailing lists to ask how they can turn something into CSS, as “tables are outdated.” In response, helpful people point to examples that were intended to show what CSS could do, rather than identify what makes logical sense.

A good rule of thumb: if you have a bunch of data that’s connected to one or more categories, use a table!

Don’t build on your “oldschool” experience, adding loads of spacer GIFs and deprecated attributes, though. Embrace the accessibility-enhancing attributes and elements you were too scared to look at back when you started sifting through the HTML specs. Some of the points you considered pointless, as they don’t show up on the screen, might come in handy now.

A header here, a scope there, some TH, TFOOT and axis …and you’ve connected the cell data to their headers, for everybody using any sort of browser — something that CSS, in all its usefulness, can’t do for you.

Taking off our CSS hats and looking at the HTML can be a very good idea. For example, why highlight a navigation item with a class called highlight when a strong element would do the same thing — and doesn’t even require CSS?

Requirements vs. Doing the Right Thing

The problem we have nowadays is that we must live with a legacy: clients and users are brainwashed into thinking that a good Website is one that looks exactly the same on every user agent, regardless of how outdated or bad it might be.

When we deal with a design that was created by a Web-illiterate designer, a hybrid table layout can still save us a lot of time and effort. If we instead use Web standards and follow the holy commandment of separating presentation and structure, we’re in trouble. Sure, we can hack and fix the design into something that does look the same on all browsers (at least, it passes the outdated and rather useless testing methodology of the client), but when we look at what we’ve produced, things can seem grim.

The CSS is full of unreadable comments and selectors that only work for this and that — and only makes sense to those who know their way around hacks; the semantically correct markup might have three DIVs where one should be enough; and…

Don’t get me wrong, we do need the Hollys and the Big Johns out there, and I am amazed at the effort they put into research and finding solutions. All the hacking and fixing is fun and technically challenging, but it does smack of browser sniffing. What happens when IE5 and 6 are no more? Will we revisit all the pages and un-hack the CSS? Hardly. If we really look into it, the problem is not the browsers or their broken implementations of CSS. The problem is the designs we’re dealing with. This is what we need to concentrate our efforts on now.

Let’s have fewer buttons linking to validators, and less evangelism about XHTML regardless of the fact that today’s user agents aren’t ready for it. Let’s have less moaning about lack of CSS3 support, and less pointing to our favourite browser that does everything so much better. Clients and users don’t care. They’ve chosen a browser that works for them, and you’d need an extremely good reason to persuade them to change.

Hit Where it Hurts

There is, however, one thing that everyone’s worried about, and people are likely to listen to you when you bring it up. Money. That’s the point at which we can start to make clients aware that good Web design to standards makes sense. Point out flaws and problems in designs and tell the client truthfully how much more time it’ll take you to eradicate these browser-specific bugs. Show the benefits of a layout that is independent of text, language, or the number of elements in the navigation system.

Advertise content management systems — after all, you don’t want to get an email or call every time the client wants to change a word in the page copy. If the client wants “cool drop-down navigation,” ask them why, and how exactly the site will benefit from the addition. Ask whether they want visitors to remember their content and products or how cool their navigation was. You’re not paid to be a code monkey: you are an interaction architect or designer, and your job is to deliver a site that works and is easily maintainable.

Let’s all get a bit less anal about the technicalities of the Web, and look at how to improve the usability and logic of the product before we start to develop it. Once this step is taken, the question of standards compliance will no longer warrant discussion.