Looks or quality?

Trick question. What you want is both.

You want a site that looks good and is coded well (to standards, with accessibility in mind). Only then can you sleep peacefully, knowing you have not wasted your money.

Don’t, whatever you do, let anyone talk you into a website built entirely in Flash. It may have bling, but that’s all. You gain too little and lose too much.

What are web standards?

To answer this question, we need to trace the way the web developed.

The origins of bad practice

In the early days of the web, designers were frustrated by the limited means at their disposal to present their layouts on-screen. After all, HTML (the web’s ‘language’) was really created to convey military and then academic information, with the ability to link from document to document. Beauty was not a priority.

Clever designers (wanting to please more commercial clients) found ways to hold layouts together with tables, slicing up graphics to place in the table cells. Complex layouts required tables within tables, like Russian dolls. At the same time, designers had to add tags to all elements to describe how they would behave. Giving font sizes, weights, families, to every piece of text, for instance. The result was dubbed ‘tag soup’ and was not pretty.

Something was lost, too, in this process. Meaning. Page elements were used any which way. Ordinary text was made to look like headlines. Lists were made by adding bullet points to text. Quotations were indicated by placing text in nested tables. Invisible ‘spacer’ graphics helped to position objects. It was a mess, and it made no sense.

Further, what would look good in one browser would not look so good in the next. Some designers, on very complex sites, took to designing for one browser only.

The cure

Those concerned about setting a sustainable course for the web’s future decided that something must be done. The core of their concern was that the content of web pages should not be cluttered up with code describing their appearance.

An example.

In the old, cobbled-together way of representing a headline, you might have seen something like this:

<h1><FONT SIZE=4 FACE="Verdana" COLOR="#FF0000">Just one
headline</FONT></h1>

Did you manage to find the actual text?

When coded properly, it should look like this:

<h1>Just one headline</h1>

A lot simpler, isn’t it?

You’re probably saying, ‘OK, that’s nice, but what if you want it to look red? Or a particular size? Or indented? Or with less distance between it and the following text? I don’t see any code that describes how it should look’.

And that is an excellent observation. All we have is code (<h1>) that says what it is. It is a headline. Not only that, but it is the most important headline on the web page. It is a meaningful element on the page.

If we want to describe how it looks (because we’re not satisfied with its default appearance) we have to do that somewhere else. All we want in the HTML code itself is meaning.

So where do we put the appearance instructions? Well, we put them somewhere else. The best place to put them is in a separate file, whose only purpose is to describe how the elements on a web page should look. This file is called a stylesheet.

In that stylesheet we might have a description for the h1. (There should be only one h1 per web page, since it is supposed to say what the page is about.) I won’t bore you with that code here, but with it you can control the size, family and colour of the type, its letterspacing, boldness, line height, distance from other elements, whether it takes its own line or shares it with following text, whether it has a border and on which sides, and more. Far, far more than was possible doing things the old way. And it will set the appearance of the h1 on every page of your website.

Of course, this means that changing the h1 code in the stylesheet changes every appearance of it on your site. Very simple. Want a new shade or colour? Just change it once, in the stylesheet.

And the same goes for every part of your website. You can change its entire colour scheme, the relative sizes of its elements and their placement; almost everything. To see an example of how one page of HTML can appear in almost infinite variations, have a look at the CSS Zen Garden

The point of all this?

When a web page is put together in this meaningful way, some exciting things result.

If a blind person visits the page, its appearance doesn’t matter. What is important is how the screen reader or braille device interprets what is there. If every element has meaning, this is simple. No struggling through tag soup. Just clearly delineated page elements.

You may think you don’t care about blind users. But that, if I may say so, is a short-sighted attitude. Many blind people depend on the web to ‘see’ the world, and you can help them to do it. If your site is easy for them, they’ll enjoy using it, and think more highly of you. (You might also be surprised to know that the law requires that most enterprises make their websites accessible to users with disabilities.)

In case that does not convince you, remember that Google is the biggest blind user of all. When Google sees your page it can ‘read’ its hierarchy. It can see what importance each headline has (h1, h2, h3 etc). It can understand that list elements are related to each other. It can see quotes, and read the invisible descriptions that say what your images are. It likes tables to be used for their intended purpose: for tabular data.

Other possibilities open up when your site is professionally coded, to standards.

Suppose you want to print a page out, but you want the print version to take advantage of the print medium. No point, for example, in keeping the navigation elements. Better to use a serif typeface, for readability. Maybe change its size, too. And make it black. We’ll put that introductory blurb in the left hand column above the main text instead. Along with a few other tweaks. Try it for yourself. Print out this page , or take a look at the print preview. (You’ll notice that all of the URLs appear after links, if you are using a good browser like Firefox or Safari. Internet Explorer 7 still won’t handle this, sadly, though it is a much improved piece of work.)

And when you come to update your site, its appearance can be changed with a few tweaks to the style sheet. Nice.

If I’ve gone into some detail here, this is because you should not be at a disadvantage when talking with a web developer. You should know what to ask for, and not settle for less.