• Choose a category
• All
• Classic-Fiction

You get control of the visual design but never complete control, which is okay because you’re trading total control for accessibility. People with devices you’ve never heard of can visit your page.

Practice a few times until you can easily build a page without looking anything up. Soon enough, you’re ready for the next step — building pages like the pros.

Chapter 2: It’s All about Validation

In This Chapter

Introducing the concept of valid pages

Using a doctype

Introducing XHTML 1.0 Strict

Setting the character set

Meeting the W3C validator

Fixing things when they go wrong

Using HTML Tidy to clean your pages

Web development is undergoing a revolution. As the Web matures and becomes a greater part of everyday life XX, it’s important to ensure that Web pages perform properly—thus, a call for Web developers to follow voluntary standards of Web development.

Somebody Stop the HTML Madness!

In the bad old days, the Web was an informal affair. People wrote HTML pages any way they wanted. Although this was easy, it led to a lot of problems:

♦ Browser manufacturers added features that didn’t work on all browsers. People wanted prettier Web pages with colors, fonts, and doodads, but there wasn’t a standard way to do these things. Every browser had a different set of tags that supported enhanced features. As a developer, you had no real idea if your Web page would work on all the browsers out there. If you wanted to use some neat feature, you had to ensure your users had the right browser.

♦ The distinction between meaning and layout was blurred. People expected to have some kind of design control of their Web pages, so all kinds of new tags popped up that blurred the distinction between describing and decorating a page.

♦ Table-based layout was used as a hack. HTML didn’t have a good way to handle layout, so clever Web developers started using tables as a layout mechanism. This worked, after a fashion, but it wasn’t easy or elegant.

♦ People started using tools to write pages. Web pages soon became so ugly that people began to believe that they couldn’t do HTML by hand anymore and that some kind of editor was necessary to handle all that complexity for them. Although these editing programs introduced new features that made things easier upfront, these tools also made code almost impossible to change without the original editor. Web developers began thinking they couldn’t design Web pages without a tool from a major corporation.

♦ The nature of the Web was changing. At the same time, these factors were making ordinary Web development more challenging. Innovators were recognizing that the Web wasn’t really about documents but was about applications that could dynamically create documents. Many of the most interesting Web pages you visit aren’t Web pages at all but programs that produce Web pages dynamically every time you visit. This meant that developers had to make Web pages readable by programs, as well as humans.

In short, the world of HTML was a real mess.

XHTML to the rescue

In 2000, the World Wide Web Consortium (usually abbreviated as W3C) got together and proposed some fixes for HTML. The basic plan was to create a new form of HTML that complied with a stricter form of markup, or eXtensible Markup Language (XML). The details are long and boring, but essentially, they came up with some agreements about how Web pages are standardized. Here are some of those standards:

♦ All tags have endings. Every tag comes with a beginning and an end tag. (Well, a few exceptions come with their own ending built in. I’ll explain when you encounter the first such tag in Chapter 6 of this minibook.) This was a new development because end tags were considered optional in old-school HTML, and many tags didn’t even have end tags.

♦ Tags can’t be overlapped. In HTML, sometimes people had the tendency to be sloppy and overlap tags, like this: my stuff. That’s not allowed in XHTML, which is a good