Refactoring - Refactoring HTML: Improving the Design of Existing Web Applications - page 18

blog aggregators, search engines, authoring tools, and a dozen other things that all need to read web pages.
These programs are much easier to write when the data you're processing is XHTML rather than HTML.
Of course, many people working on the Web and most people authoring for the Web are not classic
programmers and are not going to write a web spider or a blog aggregator. However, there are two things they
are very likely to write: JavaScript and stylesheets. By number, these are by far the most common kinds of
programs that read web pages. Every JavaScript program embedded in a web page itself reads the web page.
Every CSS stylesheet (though perhaps not a program in the traditional sense of the word) also reads the web
page. JavaScript and CSS are much easier to write and debug when the pages they operate on are XHTML
rather than HTML. In fact, the extra cost of making a page valid XHTML is more than paid back by the time you
save debugging your JavaScript and CSS.
While fixing XHTML errors is annoying and takes some time, it's a fairly straightforward process and not all that
hard to do. A validator will list the errors. Then you go through the list and fix each one. In fact, errors at this
level are fairly predictable and can often be fixed automatically, as we'll see in Chapters 3 and 4 . You usually
don't need to fix each problem by hand. Repairing XHTML can take a little time, but the amount of time is
predictable. It doesn't become the sort of indefinite time sink you encounter when debugging cross-browser
JavaScript or CSS interactions with ill-formed HTML.
Writing correct XHTML is only even mildly challenging when hand authoring in a text editor. If tools generate
your markup, XHTML becomes a no-brainer. Good WYSIWYG HTML editors such as Dreamweaver 8 can (and
should) be configured to produce valid XHTML by default. Markup level editors such as BBEdit can also be set to
use XHTML rules, though authors will need to be a little more careful here. Many have options to check a
document for XHTML validity and can even automatically correct any errors with the click of a button. Make sure
you have turned on the necessary preference in your editor of choice. Similarly good CMSs, Wikis, and blog
engines can all be told to generate XHTML. If your authoring tool does not support XHTML, by all means get a
better tool. In the 21st century, there's no excuse for an HTML editor or web publishing system not to support
XHTML.
If your site is using a hand-grown templating system, you may have a little more work to do; and you'll see
exactly what you need to do in Chapters 3 and 4 . Although the process here is a little more manual, once
you've made the changes, valid XHTML falls out automatically. Authors entering content through databases or
web forms may not need to change their workflow at all, especially if they're already entering data in a non-
HTML format such as markdown or wikitext. The system can make the transition to XHTML transparent and
painless.
The second reason to prefer XHTML over HTML is cross-browser compatibility. In practice, XHTML is much more
consistent in today's browsers than HTML. This is especially true for complex pages that make heavy use of CSS
for styling or JavaScript for behavior. Although browsers can fix markup mistakes in classic HTML, they don't
always fix them the same way. Two browsers can read the same page and produce very different internal
models of it. This makes writing one stylesheet or script that works across browsers a challenge. By contrast,
XHTML doesn't leave nearly so much to browser interpretation. There's less room for browser flakiness.
Although it's certainly true that browsers differ in their level of support for all of CSS, and that their JavaScript
dialects and internal DOMs are not fully compatible, moving to XHTML does remove at least one major cause of
cross-browser issues. It's not a complete solution, but it does fix a lot.
The third reason to prefer XHTML over HTML is to enable you to incorporate new technologies in your pages in
the future. For reasons already elaborated upon, XHTML is a much stronger platform to build on. HTML is great
for displaying text and pictures, and it's not bad for simple forms. However, beyond that the browser becomes
primarily a host for other technologies such as Flash, Java, and AJAX. There are many things the browser cannot
easily do, such as math and music notation. There are other things that are much harder to do than they should
be, such as alerting the user when he types an incorrect value in a form field.
Technologies exist to improve this, and more are under development. These include MathML for equations,
MusicXML for scores, Scalable Vector Graphics (SVG) for animated pictures, XForms for very powerful client-side
applications, and more. All of these start from the foundation of XHTML. None of them operates properly with
classic HTML. Refactoring your pages into XHTML will enable you to take advantage of these and other exciting
new technologies going forward. In some cases, they'll let you do things you can't already do. In other cases,
they'll let you do things you are doing now, but much more quickly and cheaply. Either way, they're well worth