 |  |
| |
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) kind of data. If an HTML document can exist in an open, XML-flavored world, a content author can wrap content inside a custom contextual tag that might be used in conjunction with a style sheet to create a special appearance for that kind of element. If such a document were linked to an external Document Type Definition (DTD), the document would pass XML validation, yet in all other respects, the document would behave like an HTML document.
To demonstrate how traditional web page content can (some might say should) course its way across the Net as XML data, the W3C reconfigured the HTML 4 standard so that it also adhered to fundamental XML tagging practices. The result is an XMLized HTML recommendation, or XHTML for short. Version 1.0 of the XHTML recommendation is a very thin document because it encompasses all HTML 4.01 elements and attributes. 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 the elements into 20 modules of related elements. The version of the standard that embraces this 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. For more details about XHTML 1.1 modules, see Chapter 7.
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 are deprecated, however (as detailed in Chapter 8). With only a few exceptions, the source code structure and formatting requirements of XHTML coincide with many coders' existing styles. In any case, the requirements 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 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.0 recommendation includes 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 an older browser needs 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.
Neither IE 6 nor Netscape 6 or later requires that HTML content follow the XHTML format. In fact, because these browsers (and many more versions to come) must be compatible with a web full of HTML content in the real world, the decision to follow the XHTML recommendation 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; 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, but they follow HTML 4 end tag rules. 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 handlers and other attributes that go beyond the limited set that validate 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 XHTML document types if you so desire.
|  | |
| 1.3. HTML |  | 1.5. Style Sheets |
Copyright © 2003 O'Reilly & Associates. All rights reserved.