Section I.4. XHTML

I.4. XHTML

The industry-wide drive to embrace the Extensible Markup Language (XML) way of describing electronic information had a big impact on the W3C HTML Working Group. For example, while HTML has a rigid set of elements and attributes, XML supports the creation of new elements and attributes that accommodate a new or specialized (discipline-specific) kinds of data. It was a natural extension, therefore, to reconfigure the HTML 4 standard so that it also adhered to fundamental XML tagging practices. The result is an XML-ized HTML recommendation, or XHTML for short.

I.4.1. XHTML 1.0/1.1

Version 1.0 of the XHTML recommendation is a very thin document because it encompasses all HTML 4.01 elements and attributes by reference. The bulk of the document describes how to compose HTML in a way that conforms to XML markup. Most of the XML-oriented features of XHTML govern how authors should format source code and structure elements and attributes in a document.

In concert with the trend of many W3C recommendations, XHTML evolved to embrace the idea of modularity. In place of one giant XHTML recommendation, the group divided elements into 20 modules of related elements. The first version of the standard that embraced modularization is known as XHTML 1.1. The rationale behind modularization is to allow specialized devices to support subsets of the XHTML standard that make the most sense for the content they intend to convey or the rendering facilities of the device. For example, an HTML-rendering engine embedded into a cellular telephone might not need to support the loading of external code objects. Such a phone-based "browser" could support all XHTML modules except for the Object Module, which contains the object and param HTML elements.

It is important to bear in mind that as of XHTML 1.1, no new elements or attributes were added to what had been in the HTML 4.01 recommendation. Some long-standing items were deprecated, however. With only a few exceptions, the source code structure and formatting requirements of XHTML coincide with many coders' existing styles. The requirements simply impose a more rigorous style in order to pass XML source code validation. The key requirements are:

• HTML tag and attribute names must be spelled only in lowercase characters.

• All attribute values must be quoted.

• All elements that can contain other elements require an end tag.

• All empty elements, such as img and hr, require either an end tag or must include a forward slash immediately before the right angle bracket (as in <hr/>).

• All attributes must be stated as name-value pairs, including those that had previously been defined as one-word, minimalized attributes (e.g., checked="checked").

• The name attribute is deprecated in favor of the id attribute.

• The target attribute (of the a and form elements, for instance) is not permitted in Strict validation.

Moreover, in recognition of compatibility issues with HTML code that must also run on non-XHTML-aware browsers, the XHTML 1.x recommendations include provisions for backward compatibility. For example, because older browsers may become confused by an end tag for an empty element (a </br> tag, for example), you can use the XML internalized slash technique, but with an extra space before the end slash, as in <br /> or <hr />, which older browsers accommodate. In the case of forms, where browsers continue to need the name attribute to convey the form or form control's identifier with a submission, you can assign the same identifier to the name and id attributes of a form element or form control.

Thanks to the backward-compatible design of XHTML 1.x, most HTML 4 browsers experience no difficulty with XHTML markup served as an HTML file (i.e., a file served with the text/html MIME type). A problem does arise, however, in Internet Explorer 6 or 7 and a host of earlier browsers, which do not understand the preferred MIME type for XHTML: application/xhtml+xml. The preferred MIME type is supported by Mozilla, Opera 7.1 (Windows), Opera 6 (Macintosh), and Safari 1.2.

I.4.2. XHTML 2.0

Based on the working draft of the XHTML 2.0 recommendation, numerous new markup elements and attributes are on the way. For example, any element can be made a hyperlink by simply including an href attribute whose value is a target URL. A new type of list element, nl, provides a context for navigation lists (commonly marked up today as ul and li elements) whose appearance and interaction can be independently governed by style sheet rules and/or scripts. Support for W3C activities such as XFORMS and XMLEVENTS are incorporated into this new XHTML version. Full details and the current status are available at http://www.w3.org/TR/xhtml2.

Mozilla 1.8 offers support for several XHTML 2.0 features, most typically to enhance accessibility of content and user interface elements. Because XHTML 2.0 is not fully backward-compatible with previous versions and non-supporting browsers, it is unlikely to find its way into your repertoire for several years to come if you develop content for public use.

I.4.3. HTML or XHTML?

Because even the latest browsers (and many more versions to come) must be compatible with a Web full of HTML content in the real world, the decision to adhere to XHTML markup practices is up to each content developer. If you take comfort in having your source code successfully pass XHTML validation, you can specify the XHTML document type at the top of your documents. Be aware, however, that such validation will reject proprietary attributes (such as IE-specific event handler attributes) unless they are labeled with XML namespaces. But even if you are not overly concerned with following the XHTML recommendation, you should nevertheless gravitate toward its formatting requirements, especially the top three bullet points in the list above; they will become the norm as automated authoring tools begin generating code to meet that standard.

Example listings throughout this book focus more on the scripting than the tagging. Therefore, HTML code examples in the present edition of this book follow a middle ground in the HTML/XHTML discussion. They adhere to XHTML formatting for tags and attributes. Except where intended for full backward compatibility, examples try to avoid elements and attributes deprecated in HTML 4 to instill good practice as authors move toward XHTML. Also, for the sake of demonstration clarity and brevity, tags occasionally include event and other attributes that go beyond the limited set that validates under XHTML-Strict. Unless otherwise specified, however, all listings assume a browser's default document type. If you are an experienced XHTML author, you won't have to go far to adapt these listings to more stringent XHTML document types if you so desire.