January 01, 2002
URL:http://www.drdobbs.com/xhtml-in-the-real-world/184412353

On May 31, 2001 the W3C released XHTML 1.1 as a recommendation. This recommendation is an ongoing effort on the part of the W3C to reformulate HTML into a truly extensible XML application. XHTML 1.1 provides a set of modules through which developers can extend XHTML to include other tagsets.

Okay, so you've read a lot of markup news in the past year. For many readers, it's just plain confusing. How does XHTML affect you as a Web designer—or should it? Well, if your goal is interoperable sites that work across platforms and beyond to wireless, alternative, and internationalized documents then XHTML—particularly as it extends and grows—is something you want to pay attention to.

To that end, I'd like to offer up a chapter excerpt in two installations from my recent Special Edition Using XHTML. I hope to provide those readers who have not yet delved into XHTML or XML as markup alternatives to HTML the opportunity to understand what our current problems with markup are, and how they can be ameliorated.

Assessing Present Concerns

When XML hit the scene, people talked about it as being the "HTML Killer." It turned out that they were right, but not necessarily in the sense they originally meant! Although XML has not replaced HTML as a Web markup language at this time, it has significantly changed the way HTML is being viewed in terms of standards.

This excerpt deals with a lot of complex and historical issues surrounding HTML and how it got the way it got. And, how it can be fixed. Some of my commentary might seem negative, but I want to set in your minds up front that the problems with Web markup today are not necessarily our fault. However, these problems do, at many levels, become our responsibility. After all, we're the ones paying attention. We're the ones being challenged to make our documents and designs work in the real world. Our agendas are probably quite different from those of profit-oriented software developers. So when I talk about sloppy code and how we need to clean it up, I mean that not as a criticism of past practices per se, but as an honest assessment of where we as Web authors have been, where we are today, and where we need to go to make our lives and work less frustrating and more progressive.

The Trouble with HTML

When we look more closely at what this rapid-fire growth and disregard for rules has done to HTML, we see significant degradation of the initial goal of HTML: to create documents that are readily accessible across browsers, platforms, and user interfaces. In fact, the very reasons HTML came into being were rapidly bastardized in the name of progress.

Is this a bad thing? On the side of innovation's defense, it probably couldn't have happened any other way. That rapid pace was necessary to push the envelope, and create the dynamic, wild, and profitable Web we know today.

But, looking around at the amount of HTML out there that is poorly written, it's amazing that Web pages work as well as they do—much less work at all. And although most of the Web does seem to work, the reality is that we are very limited in terms of being able to make progress, to create truly interoperable sites, and to create sites that are both well-designed and authored correctly.

Poorly Written Markup

The first and most upsetting thing about the state of HTML is that there is no consistency among the way documents are developed. Whether a person authors HTML by hand, or uses a development tool of some kind, code results tend to be as far from the standards as one can imagine.

Think of it this way. If I have two people apply for a job as an HTML author (and this has really happened), and I provide a table and ask the authors to hand code it, each of the individuals will mark it up in a different way. Part of the reason is that HTML itself is somewhat arbitrary. For example, here's one way to mark up an example:

 
<table border="1" cellpadding="0" cellspacing="0" width="50%" align="center">
<tr>
    <th align="left">Fruits</th>
    <th align="left">Vegetables</th>
    <th align="left">Grains</th>
    <th align="left">Proteins</th>
</tr>
<tr>
    <td>Apples</td>

    <td>Green Beans</td>
    <td>Wheat</td>
    <td>Fish</td>
</tr>
<tr>
    <td>Oranges</td>
    <td>Spinach</td>
    <td>Oats</td>
    <td>Chicken</td>
</tr>
<tr>
    <td>Bananas</td>
    <td>Asparagus</td>
    <td>Barley</td>
    <td>Beef</td>
</tr>
</table>
 
 

But, you can mark this up as follows:

<div align="center">
<table border="1" cellpadding="0" cellspacing="0" width="50%">
<tr>
    <td><b>Fruits</b></td>
    <td><b>Vegetables</b></td>
    <td><b>Grains</b></td>
    <td><b>Proteins</b></td>
</tr>
<tr>
    <td>Apples</td>
    <td>Green Beans</td>
    <td>Wheat</td>
    <td>Fish</td>
</tr>
<tr>
    <td>Oranges</td>
    <td>Spinach</td>
    <td>Oats</td>
    <td>Chicken</td>
</tr>
<tr>
    <td>Bananas</td>
    <td>Asparagus</td>
    <td>Barley</td>
    <td>Beef</td>
</tr>
</table>
</div>
 
 

And these are clean examples! The sad fact is that most individual-even those who have been writing or producing HTML documents for several year-will not mark up the document in any consistent or mature way. They'd leave out attributes, put in ones that don't belong (or exist), or run into problems because they've always relied on a visual editor to get the job done for them.

Now to be fair, it's important to point out that this lack of consistency and lack of knowledge has very little to do with the integrity of the individuals in question. It has ever so much more to do with the fact that the way HTML has been learned is by the boot-strap method. Early adopters used View Source and picked up others' mistakes. Later on, when visual editors became pervasive and browsers very forgiving, people relied more on what the programs were producing. As long as the page was readable, that's what mattered. And finally, the more forgiving of poor markup browsers became, the less people had to concern themselves with consistent code practices, much less standardized ones.

My goal here is to impress upon you—readers who are obviously interested in what XHTML 1.0 is offering to Web authors—how grave the situation with HTML has become. XHTML seeks, through its rigorous syntax and adherence to standard rules, to improve the quality of code. And that quality, at least at this point in history, rests in the hands of the author.

Code for Presentation, Not for Formatting

I'm a designer, interested in color, space, shape, typography, and the impact that a visual display can make on another person. I like things to look good! And, I want them to work properly. But another of the troubles that HTML has had is that it was forced, by default, into being a language of design rather than document structure. HTML was never intended to be anything but a formatting language for documents. I want to take a closer look at these concepts, and provide examples so you can see just how this problem—and those related to it—has escalated concerns about HTML's integrity.

The rapid advancements of the visual Web, and the excitement that surrounded its growth, put a lot of weight on HTML to accommodate design as well as structure. This is seen very clearly in two places: the use of tables for layout; and the introduction of presentational tags such as the font tag.

Let's revisit the table markup above. In both instances, the goal is to take tabular information and present it logically. It fulfills the purpose for which tables were brought into HTML.

But not long after, someone figured out that if you remove the borders from a table, suddenly you have a complex grid that you can use to place graphics, text, even Java applets, Flash objects, or video files. You've got a way to lay out a design. Suddenly, the very foundation of Web pages is relying on HTML elements that were never intended to perform the duties that they have performed for the last years, and will probably perform for some years to come.

Similarly, presentation of type on a page became an issue as more designers came to the Web. You had very few options before the font tag. You could rely on the default, or you could use a tag that forced a monospaced font, such as pre or tt:

This text, using pre appears in the user's default monospaced font.

This text, using tt also appears in a monospaced font.

Either way, both approaches are limited and not necessarily very elegant methods to achieve visual interest.

So along comes the font tag, and suddenly we've got ways to add some level of typographic presentation to our pages. Yes, it's imperfect display due to the limitations of Web typography—a visitor's machine must have that font face installed, the browser must support the tag, and so on.

But even more devastating to HTML as a formatting language is the absolute mess that font tags create. They work extremely poorly. You can't set a default font on a page with them, you must open and close them every time you want to change some attribute related to them, and you must open and close them within sections of your HTML, such as within each table cell. Begin with a nice, tight document (see Listing 1), and by the time you're done adding pretty fonts to a page, you've definitely doubled, possibly tripled, and maybe even quadrupled the weight of your document (see Listing 2). Plus, you've made it harder to read, harder to troubleshoot, and simply said, much sloppier.

Listing 1 - A Simple HTML Page Layout, No Fonts. Weight: 1KB

<html>
<head>
    <title>King Lear: Act 2, Scene 1</title>
</head>


<body>


<h3>Edmund</h3>


<p>The duke be here to-night? The better! best!
This weaves itself perforce into my business.
My father hath set guard to take my brother;
And I have one thing, of a queasy question,
Which I must act: briefness and fortune, work!
Brother, a word; descend: brother, I say!</p>


<p>Enter EDGAR</p>


<p>My father watches: O sir, fly this place;
Intelligence is given where you are hid;
You have now the good advantage of the night:
Have you not spoken 'gainst the Duke of Cornwall?
He's coming hither: now, i' the night, i' the haste,
And Regan with him: have you nothing said
Upon his party 'gainst the Duke of Albany?
Advise yourself.</p>


</body>
</html>

Listing 2 - Here's the Same Layout with Fonts. Weight: 2KB

<html>
<head>
    <title>King Lear: Act 2, Scene 1</title>
</head>


<body bgcolor="#000000">


<h2><font face="arial, helvetica, sans-serif" color="#FFFFCC">Edmund</font></h2>


<p><font face="garamond, times, serif" size="4" color="#CCFFFF">
The duke be here to-night? The better! best!
This weaves itself perforce into my business.
My father hath set guard to take my brother;
And I have one thing, of a queasy question,
Which I must act: briefness and fortune, work!
Brother, a word; descend: brother, I say!</font></p>


<p><font face="arial, helvetica, sans-serif" color="#FFFFCC">
Enter EDGAR</font></p>


<p><font face="garamond, times, serif" size="4" color="#CCFFFF">
My father watches: O sir, fly this place;
Intelligence is given where you are hid;
You have now the good advantage of the night:
Have you not spoken 'gainst the Duke of Cornwall?
He's coming hither: now, i' the night, i' the haste,
And Regan with him: have you nothing said
Upon his party 'gainst the Duke of Albany?
Advise yourself.</font></p>


</body>
</html>

Of course, by HTML 4.0, it became very apparent that there was a serious need to remove document presentation from document structure to bring back some rigor to HTML. So, under this concept, your basic HTML document would begin limited to document formatting elements such as is seen in Listing 1. It would then incorporate a stylesheet externally (see Listing 3), with a link to that sheet found in the head of the document.

Listing 3 - Stylesheets Allow for the Addition of Style, Separate from the Document's Formatting Elements

H2  {
font-family : arial, helvetica, sans-serif;
    color : #FFFFCC;
}
p.1  {
    font-family : arial, helvetica, sans-serif;
}
p.2  {
    font-family : arial, helvetica, sans-serif;
    font-size : 14pt;
    color : #CCFFFF;
}

However, browser support for stylesheets, which are the most lucid and useful answer to presentation and placement concerns, are to this day spottily supported across browsers and platforms, making them at best quite challenging to use in real-world situations. The irony here is that style sheets are not a new idea. They've been around since the early desktop publishing days, when the same issues came to the forefront in DTP software.

Once again, the rapid development of Web design forced HTML into corners it was too willing yet linguistically less than capable of controlling. In many ways, this is why we have the problems we have today when trying to gain consistency with layouts, fonts, and other presentational concerns.

Next week: platforms and browsers, oh my!

For more about Molly please visit molly.com.

Related Articles
To Use or Not to Use: An XHTML Roadmap for Designers By Molly E. Holzschlag
XHTML 1.0 Series Wrap By Chuck Musciano

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.