Twilight Universe

Doug Bowman of StopDesign.com recently posted a counter point to Jason Kottke’s post on standards complience and semantics at Kottke.org in which he argues againsts Jasons assertion that:

Coding web documents in valid XHTML doesn’t make them semantically useful nor does coding semantically correct documents mean the documents are standards-compliant

Dougie disagrees and thinks that it is a designers ‘natural tendancy’ to code meaniful markup if they are standards complient. Seemingly the only reason for this is his assumption that people will want to make code pretty. He goes so far to say:

A page full of nothing more than divs, spans, and br’s might be perfectly compliant in its use of standards. But generic markup like this will appear anemic in comparison to well-structured documents.

This assumes a couple of big glaring things as far as I can see..

1. Most webpages are coded by designers.
2. Most webpages coders care about the presentation of their code.
3. Most webpages are created by people that aren’t lazy.

I think these are not only Dougs assumptions, but an assumption by a lot of people in the ‘web design community’. Its a set of assumptions that have pretty much created the situation that so many of them are trying to change today - something that Doug actaully seems to understand in the last lines of his post where he says

one without the other won’t get us much further than where we’ve been in the not-so-distant past.

This is very true.

And how Doug can make that statement after a whole post of trying to persuade us that they are already skipping down the street together - if not actually hand in hand - I don’t know.

You see I actually agree with both of them. I agree with Jasons’ conclusions, but I also agree with Doug that most people who code if they do any research into standards will start to code meaningfully (semantically better).

The trouble is I have zero faith that most people will bother to learn about the code. Think about it, how many people that you know have any care what their code is as long as it looks ok when its displayed? Moreover, how many designers really want to get down and dirty with the code as long as they can use a nifty little program to create their design that doesn’t involve them actually messing with the code?

These people probably make up most of the actual ‘web designers’ that are out there, sure they may not code the big sites, or produce the best content, but by volume they are the biggest producers. I have no figures to produce, but think about it for a second… look around the web. These are the people that need to be sold on standards and semantics. Why? Because if they don’t.. then its going to be another 5 years of spacer gifs and tables filled with non-breaking space codes.

The web exploded because the average person could look at html and pick it up and code it, I know thats what I did. Standards complience should make it easier to understand the content and meaning of the code, and style sheets will make layout more obvious. However if the average joe doesn’t know this then where will the next generation of web designers and coders come from?

Why All The Fuss Over Web Standards?

Mainly this is to do with the goal of the strict standards, which is to separate style from content in web pages.

This means that the code on a web page should be structural, any tags should be meaningful not concerned with the presentation of the page. Presentation should be handled by CSS. More on CSS later.

An example of using meaningful code can be illustrated using the bold and italic tags <b> and <i>. These tags have no meaning by themselves. When we read bold or italic text we attach meaning to it however - bold is interpreted as words that are being stressed, and italic is text that is being emphasised. It is for this reason that browsers also support the tags <strong> and <em>. These two tags give meaning to the text that cannot be conveyed by style alone.

If you need to change a section of text to bold for stylistic purposes then you shouldn’t be using <b> or even <strong> in your code - you should be using style sheets to do that. That is what they are for.

Why Is Meaningful, Style Separated Code Important?

For two reasons: Portability and Accessibility.

Portability means that your code will be understandable not just across different browsers like IE and Mozilla, but across different platforms. This includes computer OS’s like Windows, MacOS, and Linux, but more importantly across platforms like mobile phones, PDA’s, and other equipment that can access the internet. While all of these may not be supported straight away these methods will allow your code to be transferred into the right format with the minimum of effort. Who can say that about a page with miles of nested tables?

Accessibility means that users who may not be able to use the net like the majority of people can access your site. They may use screen readers if they are partially sighted or blind, or have special browsers to make things more convenient. Either way the content of your site will still be viewable and meaningful to them. Not only is this allowing more potential viewers of your site, it may in fact be a legal requirement now for many businesses.

Basically it is maximising the availability of your content. This means that more people can see your work. Of course there are other more practical benefits to using style separated code as well, I’ll cover these as I go on.

The Concept of Tableless Design

Tables are another example of where structural code has been misused for design purposes. In the past it was common to work out a way where you could split your design into rows and columns so you could display it in a table. It is such a common way of thinking now that many web designers have trouble not thinking in these terms.

However tables are designed to display tabular information, not to act as a stylistic tool. This is where the idea of tableless design comes in - using tables only to display tabular information. If your content requires a table, by all means put a table in there. What you should not be doing is using them to control the layout of your page. This just leads to ugly, nested tables, lots and lots of code and, above all else - a website whose’ content is meaningless.

Sometimes it can be useful to use tables to define the basic structure of your page. In this case it is a semi-valid use - it is a structural element after all, and this method may help display your page in some older browsers that don’t support style sheets. However I would not suggest it, mostly because there is no need to do so, and it can lead to more problems than it solves. It is a good solution for people just getting into style sheets and learning how to work with them though.

Rather than thinking of your page as a set of rows and columns, think of it as if it is split into any number of boxes. In each box is an element of your page. These boxes don’t have to be aligned with each other, or even be next to each other - they could overlap for example. This is the concept of tableless design.

Each box would be an item, be it an image, a block of information enclosed in a <div> tag, some text in a <span> tag, or anything else on a page. Each of these elements would be controlled and positioned using CSS, allowing much greater flexibility in design, while keeping your actual code clean and simple.

How Does This All Benefit Me?

Coming down to brass tacks, most viewers don’t care how their page is coded, just that it displays properly. So what does all this mean in a practical sense? As Jerry Maguire might say - show me the money.

• Smaller Pages - Because you aren’t using lots of nested based markup that wasn’t designed to be used for presentation or tag specific attributes you’ll find that the pages you author are smaller in file size. Meaning that you use your web space better, and have more room for more content.
• Faster Loading, Lower Bandwidth - because your page size is smaller and the style sheet only needs to be loaded once you’ll find your pages loading faster. Being smaller also means you’ll use less bandwidth - which saves you, or your client, money.
• Less Work - That’s right, less work for you. Coding and working with table based layouts can be time consuming, and boring. You end up repeating large blocks of your code needlessly - especially when you are using the same or similar layout in every page (as almost all sites do). If you separate the style from the content all you need to do to design your entire site is to work with one file.
• Easy To Redesign - have you ever tried to redesign a nested table layout that you coded a year or two before? If you have then you’ll know that it is a tiresome and will sapping task - and that’s when you coded it, let alone some other developer. When the content is separated however all you have to is change the style sheet and you can have a totally different look in minutes.
• Get The Design You Want - Often many designers have had to compromise their design because certain things just weren’t practical. With style sheets designers have full control over their design and, while not as flexible as a professional design package, much more can be done - like pixel based layout for example.
• Access To More Viewers - If you code and design intelligently then more people will be able to see your site than ever before. Also you could be saving you or your client possible legal issues in the future.

Hopefully this demonstrates not just the usefulness of complying with web standards, but the business sense it makes - both in short and long term. A design will have less problems, a coder will have less headaches, and a client will save money.

Just remember all this for the next time you hear someone say that there is no reason to use web standards.

Currently I’m covering the simple - but important - concepts that I think everyone should know so they can create better web content, design, or code. The last entry was about DocTypes, and how they can help you be standards compliant. However, this leads to other questions…

What Is Standards Compliance, and Why Is It a Good Thing?

The term ’standards compliance’ tends to be flung around quite a lot these days, often incorrectly, or at least with some degree of misunderstanding.

All standards compliance means is that web sites and browsers confirm to certain suggestions made by the w3 organisation. These ‘recommendations’ for each form of html and other web languages form the standards. The ultimate goal of this is so that sites will look the same no matter what platform you view them on.

Its that simple, standards mean you can rely on your code acting the same, and being understandable, in different browsers and on different platforms. Sounds easy doesn’t it?

However this is where it gets tricky. Currently no single browser is standards compliant. None of them. They all claim to be, but they lie. The ones with the least bugs (very few) are Mozilla and Opera. Internet Explorer does the job, especially in v6, but still has many more problems then either of the other two. One thing to note about Mozilla and Opera is that they update much more than IE, and this is almost certainly the primary reason for their better support.

These bugs shouldn’t be a problem for many designers however, as often (though sadly not always) these bugs may not cause an obvious problem, or they have simple workarounds. Soon, I hope, there will be no need to have workarounds.

The Bottom Line

Authoring your web pages to be standards compliant will make sure that your site is seen by more people how you want it to be seen. That is better for the viewer, and better for you.

To start this off in the next few posts I’ll be covering the basics, and yes, some people may think the following is obvious, but it never hurts to make sure that everyone is on the same page.

Why You Should Be Using DocTypes

Using a correct DocType is the single most important thing to do in creating a webpage. Sadly many authoring tools actually insert incorrect or broken doctypes in the code they create. Doctypes are what tells the browser the kind of page it is expecting. This is especially important as correct doctypes help browsers to render the page in ’standards compliant’ mode, turning off all the goofy features that other, badly coded, pages might need - and that screw up all your hard work.

Of course you don’t need these features because your web page is going to be coded properly right? Right? Right.

Why are there these features in browsers? To compensate for the awful coding people have done in the past for the sake of ‘backward compatibility’ that’s why. Its the browsers fault originally of course, the war for dominance in the browser market created many of the problems that are now trying to be fixed. Due to this many web pages have code that is frankly incompetently coded - with unclosed tags and typos within the code. Putting a doctype in your code lets the browser know that you are coding to a certain specification, and that it should display it as such.

In fact having a doctype (and code that complies with it) is the single biggest step anyone can take to making their site look good, and more importantly consistent, on all platforms.

So What Is A DocType?

DocType stands for ‘document type declaration’ or ‘DTD’ and basically does just that - declare the type of document that it is. They usually come in 3 flavours - Strict, Transitional, and Frameset.

• Strict - Strict is just that, its a strict set of rules that conform to the wc3’s recommendations for web standards. It doesn’t allow any tags or properties that have been depreciated in the specification, and you should have content and presentation separated. Ideally this is what you should be working with, especially if you are creating a site from scratch.
• Transitional - Much friendlier for many people, transitional understands that you may not be able to, or may not want to code to the ideals of the strict doctype. It features the depreciated attributes, and doesn’t require you to remove content from presentation as much. A good doctype to start with if.
• Frameset - This is the same as transitional, but with support for the outdated and often misused html frames.

DocTypes also vary depending on what language you are coding in, HTML, XHTML 1, or XHTML 1.1. The difference between html and xhtml is subtle, but important. However I’m not going to cover this today, if you don’t know the difference then you are very probably using html.

What DocType Should You Use?

Good question, its quite hard to find correct doctypes on the net, even when someone declares one it is often wrong. To explain why lets look at a DocType, in this case for HTML 4 Strict:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN”
“http://www.w3.org/TR/html4/strict.dtd”>

This pretty much breaks down to three sections. Telling that its a public doctype for html, the actual definition of the type, and the url to the specification of the type. Note the FULL url in the code. Often this is written as ‘TR/html4/strict.dtd’ or ’strict.dtd’ this is wrong! You must include the full url in the doctype else it is invalid and will do nothing for you.

With that lets show you the valid doctypes:

HTML 4.01 Strict

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN”
“http://www.w3.org/TR/html4/strict.dtd”>

HTML 4.01 Transitional

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”
“http://www.w3.org/TR/html4/loose.dtd”>

HTML 4.01 Frameset

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Frameset//EN”
“http://www.w3.org/TR/html4/frameset.dtd”>

XHTML 1.0 Strict

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

XHTML 1.0 Transitional

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

XHTML 1.0 Frameset

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Frameset//EN”
http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd”>

XHTML 1.1 (No transitional or frameset)

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN”
“http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>

That’s all of them. They go just like that in your code as the first thing in the file before any other tag, even the html tag. You can check that you are conforming to the standard that you’ve declared in your doctype by validating your code (check the links side panel for the w3.org’s validator). You should try to eliminate any warnings and definately get rid of any errors it displays. In the long run you’ll learn how to code better displayed pages so that your site is fast, and the design looks right across all platforms.

Congratulations on the first step towards a better web.