To Use or Not to Use: An XHTML Roadmap for Designers

In: Articles

By Molly E. Holzschlag

Published on January 7, 2001

January 26th, 2001 marks the first birthday of XHTML 1.0 as the W3C recommendation for Web markup. But XHTML has yet to toddle, yet to smile, yet to cry loud enough so as to get the attention of most Web designers.

The problem with XHTML 1.0 isn’t a matter of strength, or of importance. XHTML is both strong and important–and not just for markup snobs and hardcore developers. It’s not that XHTML 1.0 has a particularly high learning curve. It doesn’t–in fact, it’s quite easy to learn. And, it’s not that XHTML 1.0 doesn’t display in browsers both current and past. When written with awareness of cross-browser considerations–just as with HTML, it does.

The problem lies in the fact that XHTML is, quite simply, misunderstood.

Why this misunderstanding exists is a bit more complicated. On a very basic level, XHTML breeds fear in some people because it’s XML–and XML sounds a whole lot more abstract than HTML ever did. For the experienced designer who has a more intimate knowledge of HTML, the rationale for XHTML 1.0 can be a bit hard to get at. I mean, who wants to try and decipher W3C documents anyway? Typically convoluted, overly detailed, and most definitely not-user friendly, W3C specifications are not written with the right-brained, creative personality in mind.

Finally, the software companies who provide designers with visual design tools and HTML editors have mostly ignored W3C recommendations to begin with, much less adopted as part of their tool sets. So, for the designer who wants to focus on design rather than markup–well, he or she has to trust that the software manufacturer is adhering to current recommendations.

As a result, the busy designer–if fortunate enough to have a few days to sit down and research current recommendation support in software, or whether XHTML 1.0 makes sense to use, has to unravel so much stuff to get to the point that it’s an exhausting proposition.

Kind of like taking care of a one year old.

First, What the Heck is XHTML?
It’s important to begin with an understanding of what XHTML is. To do this, let’s take a quick look back at the history of HTML. For some readers of Digital Web this information is old hat. But it’s going to be the essential kernel from which decisions about XHTML are made, so bear with me.

HTML evolved from the Standard Generalized Markup Language, SGML. SGML is what’s referred to as a “meta” language. It exists to create other markup languages. SGML is essentially a collection of language rules that authors then use to create their own document methods. HTML is one of the resulting languages–a child, if you will, of its meta-parent SGML.

Another child of SGML is XML, the Extensible Markup Language. Interestingly, XML is also a meta-language. It, too, exists as a means of creating other languages. The thing to understand about SGML is that it’s a very complex meta-language, extremely detailed. XML emerged as a streamlined meta-language suitable for creating Web markup languages that are customizable and flexible for the needs of specific applications. Examples of XML markup applications include Scalable Vector Graphics (SVG), Synchronized Multimedia Integration Language (SMIL), and Wireless Markup Language (WML).

XHTML is the reformulation of HTML as an XML application. In other words, XHTML looks at HTML through the eyes of XML. The rules and methodologies of XML are applied to HTML, bringing syntactical strength back into HTML, which lost that strength during its rapid evolution from text document markup language to the de facto language of visual design.

XHTML 1.0 is the first version of XHTML, which is a fairly rigid markup language. Its rules are very straight-forward, and there’s really little extensibility involved in XHTML in that you can’t write your own definitions as to how the language behaves. You’ve got to follow the rules. XHTML 1.0 also adopts concepts introduced in HTML 4.0–which in and of itself asks some structured behavior from anyone using it to markup documents or creating software-be it a visual editor or a Web browser.

Digging Deeper
In its early life, HTML was very simple. It existed wholly to identify a given document as being an HTML document, and allow for some very basic formatting–paragraphs, line breaks. Designers must remember that the Web was first a text-only environment! HTML was not developed with presentation concerns in mind. Rather, its goal was the structuring of data.

Enter the visual browser, which changed this text environment from one constructed of text documents to one that promised growing opportunities for visual design. HTML-and Web browsers themselves–were stretched out of proportion in order to accommodate the rapid-fire pace of the Web’s visual and interactive growth. Designers, especially, were naturally more concerned with creating designs that were visually rich and esthetically pleasing.

Trying to manipulate HTML to do what you want is pretty frustrating right? No consistent layout support. No consistent way to control white space. No stable way to manage type. A designer’s nightmare–born of the very fact that the Web was never intended to be a visual environment. But it became one, and how to manage that reality has been a challenge ever since.

Admittedly, presentation has always seemed to have taken a back seat with the committees who work on markup languages. CSS might ideally bring a lot more control to designers, but we all know that this is the stuff that turns our hair gray. For designers, the real issue boils down to needing better tools to control design–not technology.

The Cold, Hard Truth
The fact of the matter is that XHTML is not about presentation. What XHTML does do is revisit the concept of strong markup for documents. Using XHTML will help you strengthen the structure and syntax of your markup. Why is this even important? Well, if you consider the direction that technology is going, it makes a lot of sense. The future information designer will have to include numerous user agents in his or her plan. The browser-based Web with which we are so familiar is no longer the only consideration. Documents will be required to appear esthetically pleasing on the Web as well as pleasing and logical in numerous environments–pagers, PDAs, cell phones, etc.

XHTML enables any creator of documents, whether designer or developer, to stabilize that document, which makes it more interoperable. XHTML also allows you to use Extensible Style Language, XSL, with transformations. By using this XML-based style technology, you can actually transform a document from one type to another–say from an HTML document to a PDF document. What’s more, learning to author XHTML documents helps designers unfamiliar with programming or more abstract markup transition into the extensible world. Using XHTML means using vocabulary you’re familiar with–the HTML tags and attributes you work with every day. But, you’re doing it in the context of XML, and that means that when you move to pick up other XML technologies, it’s going to be that much easier. Learning XHTML means that learning SMIL and SVG will be all that much more easy.

And XHTML–in coordination with emerging technologies, is also moving us toward options that will allow us to profile a user agent and deliver the appropriate document based on that profile–on the server, not client-side, which means no JavaScript and therefore no cross-browser/user agent considerations. This is all really powerful stuff!

But what’s it got to do with a visual designer concerned with and only with designing for the Web? The cold hard truth is, not much.

And herein lies the real question that designers must ask when mapping XHTML into the plan. Are you looking for a means to control visual design for the Web? Or, are you looking for ways to extend your information to other agents such as wireless devices? This is the heart of the matter. If you have no interest in expanding beyond the Web, then XHTML only offers a few advantages, and in some cases may even cause you harm.

When to XHTML, When to Punt
It’s imperative that designers view XHTML 1.0 as a transitional methodology. It’s here now, but its goals appear to be more about stabilizing technology than advancing it. Newer versions of XHTML and other technologies will do that. So realistically, despite the fact that it is the current Web markup recommendation, it may not be the wise choice for you.

When do you use XHTML 1.0? Consider these questions:

• Do you see a need for your work to be extended to other delivery mechanisms such as wireless devices now or in the future?
• Do you want an educational tool that will transition you and your colleagues from HTML to the XML world with relative ease?
• Do you want to bring syntactical strength to your Web documents, even if it means compromising certain visual considerations?
• Are you concerned with following W3C recommendations in order to promote more stable support from the developers of browsers and Web design tools?

If you answered “yes” to any one, or any combination of these questions, then XHTML 1.0 is something you might seriously wish to consider.

If Yes, Then XHTML 1.0
If you want to look at XHTML 1.0 a little more closely, begin by assessing the information needs of your design group. If you’re a one-person shop, it’s going to be a bit of a commitment to learn XHTML 1.0 and transition documents. If you are an art director or designer working with a team–this is something you may recommend to your HTML folks to look into. There are some excellent resources on XHTML that are much more accessible than the W3C documents, I recommend them in the Resources section at the end of this article. This will get you or your document folk off to the right start.

There are some considerations of which to be aware when saying “yes” to XHTML 1.0:

• Be aware of presentation limitations. Even though it’s not required in transitional XHTML 1.0 documents to use CSS for presentation, some proprietary tags and attributes have been omitted from the transitional definition for XHTML. The ideal XHTML document relies on CSS for presentation. But we all know that CSS, despite its promise, is less than ideal in the way browsers support it. A perfect example of this is anything to do with box properties. Margins and borders are especially problematic. Let’s say you’ve been using the topmargin="x" attribute in your body tag to gain more control over your margins. Well, you can’t do it in XHTML. The topmargin attribute was left out of the definition, and CSS support is inadequate. As a result, you lose effective, interoperable control of margins in valid XHTML documents.
• Be aware of integration concerns. Do your sites integrate markup from any other source? One example of this that I learned the hard way came with markup that is provided to WebReview.com by its ad servers. The markup is poorly formed, and when dropped into our sexy new XHTML documents, renders them invalid. Do they still display? Absolutely. But do the documents validate? No, they don’t. Any markup that comes at you from another source will have to be rewritten to comply with XHTML syntax. If that markup is delivered dynamically, you’ll be facing the difficult task of convincing the individuals responsible for that markup to switch to XHTML–as if doing it yourself weren’t time consuming enough!
• Consider the scope of your project. Transitioning large sites to XHTML is a decision that is entirely up to you. You might end up dealing with concerns, as I have, that your markup doesn’t validate as XHTML despite your best intentions because you didn’t assess what ad codes might do to the site. When you’ve got a few pages, that’s one thing, but when you’ve got 10,000 pages, it’s maddening! What’s more, once you’ve made the choice of using XHTML, you will also need to consider that some of those documents will require further technologies, design approaches, or updates in order to effectively reach wider audiences via wireless or alternative devices.

This is by no means a complete list, but it’s a short list of the major walls I’ve come up against when using XHTML 1.0 in real-time. Hopefully, these points will help you avoid similar pitfalls.

If No, Punt Gracefully, Please
Despite the fact that this article is geared toward helping designers, the bottom line is that technology is what we do–even if our primary job is to make esthetic decisions about the way things look rather than the way they work. Web markup is innately related to design. Without a proper understanding of markup, the designer is at a disadvantage.

Part of the challenge designers have with markup is that they haven’t paid attention to recommendations at all, much less what’s going on with XHTML. Whether because we have such limited time to spend studying, or the difficult learning curves, most designers aren’t even using HTML that conforms the HTML recommendations set forth by the W3C, much less prepared to use XHTML.

Let’s back up for a sec and examine what standards are. The goal of a standard is to create consistent implementation of a given technology across the boards. In an ideal world, this would mean that all manufacturers of browsers and visual editors would adhere to a certain level of consistent technology. There are all kinds of technical standards. And, we refer to what the W3C puts out as “standards.”

However, use of this language is faulty. The reason is that HTML and XHTML as defined by the W3C are not standards. They are recommendations. The W3C working groups consist of intelligent, visionary individuals and companies seeking to produce thoughtful guidelines by which to create, grow, and guide the Web technologies we use. But they are not the boss of me. Or you. You don’t have to follow the recommendations–and in fact, most people do not!

But, there are advantages to doing so. If you decide to not use XHTML 1.0, I’m very concerned that you at least consider following the recommendations set forth by the W3C for HTML 4.0 (specifically, HTML 4.01, which is the final version of HTML).

If we are not self-policing, it’s that much harder to suggest to any company delivering a browser or a design tool to be as well. And that potentially hurts us as designers, because we lose consistency. This can be clearly seen with CSS, and it is even more clearly demonstrated with what happened recently when Netscape 6.0–in a valiant effort to support the W3C recommendations as thoroughly as possible–intentionally left its own proprietary layers tag out of the browser. This issue is really upsetting to designers, but the alternative perspective is that at least we begin at the same starting point and work from there. We don’t pull out our hair worrying which browser will or won’t support our designs. We know they either will, or they won’t, and that’s incredible empowerment for us.

What About the Future?
If you’ve been thinking that following recommendations such as HTML 4.0 or XHTML 1.0 is pain enough, Modularization of XHTML, which entered W3C Candidate Recommendation status as of October 2000, is bound to leave you reaching for the Advil. Or a stiff shot of pepper Vodka–whichever is closer.

XHTML Modularization, when compared with XHTML 1.0, is extremely abstract–but in many ways more powerful, giving more control to the individual who’s examining which markup methods work best in a given situation. The idea with modularization is that individual control as to what we need when structuring a given document is paramount. All of the components of Web markup: images, tables, text formatting, and so on, are separated into modules. Then, a document type definition (DTD) can be written calling on any of the existing modules as needed. So, if you only wanted text and images in your documents, that’s all you use. The resulting markup is very uncomplicated–which makes a whole lot of sense when you’re structuring information for a wireless device. But, if you’re focused on designing a complex layout with rollovers for a Web page, it’s pretty near useless.

Ultimately, XHTML is not something designers should heartily embrace unless there’s a real need to do so. I am personally committed to supporting W3C recommendations–so much so that I’ve spent the last year of my life educating people about XHTML and what its advantages are. However, I live and work in the real world, too, so I can’t afford to just be an evangelist. I have to look at the realities, and at the end of the day, it is clear that XHTML was never made for the designer. The harsh reality is that HTML was never made for the designer, either. And usability freaks step aside, please, because the only successful Web technology that’s truly been created with designers in mind is Flash. SVG and SMIL are emerging as potential opportunities, but the implementation for each is limited at this time, so they’re not real contenders yet.

But of course, our futures as Web designers requires that we learn about and sometimes embrace new technologies. Whether you decide XHTML is something that makes sense for your goals or not is an extremely personal decision. But learning the issues, staying as current as possible with W3C recommendations, and making informed decisions as to which technologies you implement empowers all of us in the end. And that’s a very worthy goal.

---

Resources

Articles
“Marking Up Documents in XHTML”
Helpful tutorial from the HTML Writer’s Guild.

XHTML 1.0: Marking up a new dawn “Getting familiar–and getting started–with the new standard” by Molly E. Holzschlag
A detailed technical tutorial that will get you started writing your XHTML documents.

“All About XHTML” by Molly E. Holzschlag
An XHTML tutorial geared toward folks interested in wireless development.

Books
“XHTML: Moving Toward XML” by Simon St. Laurent and B.K. Delong, Hungry Minds, Inc.

“XHTML for Dummies” by Ed Tittel, et. al., IDG Books

“Special Edition Using XHTML” by Molly E. Holzschlag, Que Publishing

Software
BBEdit for the Mac now supports XHTML, http://www.barebones.com/

Pagespinner for the Mac also supports XHTML, http://www.optima-system.com/pagespinner/

Mozquito Factory 1.5 is built specifically for XHTML, available for Windows, Linux, Mac, and Unix, http://www.mozquito.com/

Mailing Lists
XHTML-L is an excellent list started by Simon St. Laurent with hot topic discussion on XHTML issues. Geared to participants of all levels. http://www.egroups.com/group/XHTML-L

Related Topics: XHTML, HTML