HTML, XHTML and CSS All-In-One for Dummies - Andy Harris [17]
♦ Everything’s lowercase. Some people wrote HTML in uppercase, some in lowercase, and some just did what they felt like. It was inconsistent and made it harder to write browsers that could read all the variations.
♦ Attributes must be in quotes. If you’ve already done some HTML, you know that quotes used to be optional — not anymore. (Turn to Chapter 4 for more about attributes.)
♦ Layout must be separate from markup. Old-school HTML had a bunch of tags (like and
This sounds more like strict librarian rules. Really, they aren’t restricting at all because most of the good HTML coders were already following these guidelines or something similar.
There’s XHTML and there’s good XHTML
In old-style HTML, you never really knew how your pages would look on various browsers. In fact, you never really knew if your page was even written properly. Some mistakes would look fine on one browser but cause another browser to blow up.
The idea of validation is to take away some of the uncertainty of HTML. It’s like a spell checker for your code. My regular spell checker makes me feel a little stupid sometimes because I make mistakes. I like it, though, because I’m the only one who sees the errors. I can fix the spelling errors before I pass the document on to you, so I look smart. (Well, maybe.)
It’d be cool if you could have a special kind of checker that does the same things for your Web pages. Instead of checking your spelling, it’d test your page for errors and let you know if you made any mistakes. It’d be even cooler if you could have some sort of certification that your page follows a standard of excellence.
That’s how page validation works. You can designate that your page will follow a particular standard and use a software tool to ensure that your page meets that standard’s specifications. The software tool is a validator. I show you two different validators in the upcoming “Validating Your Page” section.
The browsers also promise to follow a particular standard. If your page validates to a given standard, any browser that validates to that same standard can reproduce your document correctly, which is a big deal.
XHTML isn’t perfect
While XHTML is the standard emphasized in this book, it has a few problems of its own. Not all browsers read it the same way, and it’s a bit wordier than it needs to be. It looks like the next generation will go back to a form of HTML (HTML 5). However, proper HTML 5 coding will resemble XHTML more than HTML 4. In this edition, I focus on XHTML Strict. See Chapter 8 of this minibook for a complete overview of this important standard.
Building an XHTML Document
You create an XHTML document the same way you build ordinary HTML. You can still use an ordinary text editor, but the code is slightly more involved. Look at the following code (template.html on this book’s CD-ROM) to see a bare-bones XHTML document:
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
At first, this new document looks a lot more complicated than the HTML you see in Chapter 1 of this minibook, but it isn’t as bad as it seems.
Don’t memorize all this!
Before you freak out, don’t feel you have to memorize this nonsense. Even people who write books about Web development (um, like me) don’t have this stuff memorized because it’s too awkward and too likely to change.
Keep a copy of template.html on your local drive