Moving to Modules: Creating Extensible Document Structures with XHTML 1.1

Overview

While most of the article up to this point has repeated the mantra "XHTML is just like HTML, only cleaner," it's time to move into some of the more radical possibilities this giant cleanup has made possible for XHTML. The housecleaning performed so far is only the start – a full remodeling of HTML is on the way. The W3C firmly believes that XHTML is the future of HTML, and it has some large plans hinging on XHTML's development.

Note To get a clearer picture of what the W3C has in mind for XHTML, explore the HTML Working Group Roadmap at http://www.w3.org/TR/xhtmlroadmap/. This document describes the end of development on HTML as well as the next few steps — roughly a year's worth of plans — for XHTML 1.1 and XHTML 2.0.

Different Needs, Different Tools HTML is running out of steam. As the Web reaches beyond browsers on PCs, HTML is proving both too large (for cell phones) and too small (for many sophisticated applications). The one-size-fits-all approach that has suited HTML so well is causing problems as the Web continues to succeed. Although HTML has never been forced into a single size, with browser-specific variants and the three DTDs approach of HTML 4.0 and XHTML 1.0, HTML as a whole is both too enormous and too limited. When HTML first appeared, browsers were relatively small and easy to fit on a single disk or embed into tiny computer. But after a few rounds of competition, they've grown enormous. (The Opera browser has avoided bloat, but it's a very clear exception to the rule.) Part of this expansion has to do with the ever-growing tendency to expand browsers beyond simple HTML processing. But a considerable amount of the extra code has been necessary to process new features added to HTML over the years. Opera, and now Mozilla (the code base for Netscape Navigator 6 and beyond), was built from the ground up with the latest features in mind. Meanwhile, the older versions of Netscape Navigator – and some extent Internet Explorer – include a lot of code that layers new functionality on top of old. This isn't necessarily a bad thing – at least until the browser size reaches some serious bloat – because it helps browser vendors get their products out the door and keeps costs down. Over time, however, the changing nature of the Web browser market has piled new code inefficiencies into browsers. The browser orientation of HTML has also had an effect on the expectations of those who design for Web pages. Even in cases in which developers carefully check their sites across multiple versions of browsers on multiple platforms, there always has been an underlying assumption that a large core of HTML is available on every product calling itself a browser.

As browsers have grown more sophisticated, developer expectations have risen. Most sites today, for instance, assume that users have browsers that support tables – once a risky proposition. Many sites assume that browsers support JavaScript, and a lot of sites assume that users have various plug-ins such as Flash or Acrobat. When WebTV first appeared, Web designers sounded off for months on various mailing lists. They complained about the company's compromises to put HTML content onto television screens and bemoaned missing features. A fair number of people didn't find WebTV acceptable as a candidate for serious Web design. Nonetheless, WebTV remains on store shelves and in people's homes, Microsoft has bought out the company, and similar alternatives for low-cost home browsing continue to appear. Cell phones, and to a lesser extent PDAs, face an even more difficult situation. They have neither the screen real estate nor the luxury of a large box that sits in a single location. With their tiny screens and lightweight processors, these devices can't process HTML's many complexities efficiently – nor can they display the full content of what they process even if that were easy. Combine these difficulties with the tiny amount of bandwidth available through their typically wireless connectivity, and cell phones are left stranded by HTML in its present form. Vendors have had to develop their own HTML subsets and infrastructures to cope with these problems, as described in Article 17, and HTML is only catching up now.

Going the other direction, Web browsers today make very little use of the processing capability available on client machines. While they may have sizable memory and processing footprints as a result of their code for interpreting and presenting HTML, Web browsers act largely as passive presenters for serverside processing. While you can start Java applets and ActiveX controls from within HTML, and plug-ins can add functionality, none of these really work within HTML itself. They all need information in their own formats, and developing these tools typically means building an HTML shell and then working on anything but HTML. To some extent, recent browser generations have built stronger HTML processing capabilities into their cores. The development of the Document Object Model (DOM) is a milestone, providing a standardized way for scripts to access information that arrives in HTML (or XHTML or XML) and to modify that information. It's now possible to build sophisticated interfaces that help users find information within documents, or change document presentations to meet different user needs. You also can achieve some processing of information, although that processing is performed on a document-by-document or site-by-site basis. These capabilities are all custom coded right now, and they rely on tools that aren't implemented widely yet.

Netscape woke up Microsoft and earned its undying enmity at one point in the browser wars by proclaiming that browsers would replace operating systems. This announcement directly threatened Microsoft's primary source of profits. Browsers still don't live up to Marc Andreesen's 1996 claim that, "The only difference technically between Netscape's Navigator browser and a traditional operating system is that Navigator will not include device drivers." ("Netscape's Andreesen Eyes Internet OS," PC Week, June 17, 1996.) This "big browser" vision hasn't come to pass, although Microsoft's own version of operating systembrowser integration has brought it to court. In large part, though, what has kept it from appearing isn't the Department of Justice or Netscape's collapsing market share. It's simply because HTML hasn't proved a very good foundation for these endeavors. Operating systems are environments for processing any kind of information with a variety of interfaces, while browsers are environments for presenting documents with a relatively limited set of interfaces and inefficient scripting logic to boot. Making these kinds of visions possible, whatever the vendor politics, requires adding new functionality to the foundation of the browser universe – HTML.

The Master Plan: Fragmenting and Extending HTML The W3C has been trapped in something of a dilemma since it first started its work. While the W3C exists "to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability," a large part of its appeal has rested on its authority to codify an "official" flavor of HTML. Web developers looked to the W3C to produce standards they could hold browser vendors to, while the W3C saw itself largely as a research lab pushing the envelope on experimental technologies. The fact that the same browser vendors who were making users crazy were the primary participants and funders of the W3C probably hasn't helped, either. At the same time that the W3C wants to maintain its role and its reputation as the sole home of HTML, lots of proposals both inside and outside of the W3C have been itching to add new features to HTML. In some cases, such as Microsoft's addition of an xml element in Internet Explorer 5, they simply have moved forward with their own plans. In other cases – such as the W3C's hopes of adding Synchronized Multimedia Integration Language (SMIL), MathML, or Scalable Vector Graphics (SVG) to browser vocabularies – they've remained mostly stuck, unable to convince vendors to build these standards into their browsers.

Some of the problems lie in the politics of standards creation and adoption, which can range from the pleasant to the poisonous. It isn't clear that Microsoft, currently dominating the browser market, has much to gain from fully supporting the W3C specifications that it helped to create. Meanwhile, Netscape – trying to recover from a few years of free-fall – has embraced the W3C's standards (some of them at least) emphatically in Mozilla. While the competitive nightmares of the browser wars create incompatibilities, the incentives for accepting and implementing open standards tend to disappear when competition fades. Escaping from this trap requires taking a different perspective on the Web and Web infrastructures. The business environment behind the Web isn't likely to change in a substantial way, so perhaps making relatively small changes in the technical infrastructure can create new openings for enhanced capabilities. Plug-ins and similar infrastructures (ActiveX controls, Java applets, and so on) have been adjuncts to HTML so far – only used in a limited number of situations and typically acting on information that comes from outside the HTML document itself. XHTML modularization squares the circle, providing vendors with a standardized way of creating their own extension vocabularies while developing an opening in the infrastructure that makes it possible for those uninterested in building their own browsers to make substantial contributions. Modularizing XHTML doesn't guarantee that developers will follow up on W3C standards with modular browsers, but it might add incentives for doing so. At the very least, XHTML modularization provides a framework that developers can use on the server side for integrating XML and HTML vocabularies; and perhaps the client-side tools will catch up as well.

By embracing the diversity the W3C originally was hailed for quashing, and by enabling developers to add to the mix in a much more controlled way than was possible when vendors just threw in their own elements and attributes, the W3C hopes to open HTML up without polluting it. The W3C isn't defining any kind of program infrastructure to support modularization, but hopefully some kind of infrastructure will emerge that supports modularization in an unambiguous and widely useful way.

Didn't Namespaces Solve Everything? Another W3C Recommendation, Namespaces in XML, provides developers with a set of tools for identifying elements and attributes as HTML elements, SVG elements, MathML elements, or My elements. Browsers can home in on this information, and present the information in a way that reflects the element type correctly. Among other things, this means that users can drop html:img elements into XML documents for use with Internet Explorer 5 and Netscape 6 and actually get images to appear in the browser window. As powerful and as useful as namespaces are, however, they don't address an enormous number of issues. Two critical problems are context and registration. Context issues arise when vocabularies are mixed, while registration problems emerge when you use namespaces in environments that don't have a way of dealing with them. XHTML modularization is designed to address the context issues. The registration issues remain for another set of tools described at the end of this article. Context issues typically arise from the nested nature of XML documents. If all the pieces in a document can stand alone (as separate paragraphs, for instance), then an application shouldn't have any significant difficulties processing information as a series of standalone pieces. But if a fragment from one vocabulary is dropped into another vocabulary, it isn't clear how an application should handle it. For example, the following elements are derived from XHTML and SVG:

   <html  xmlns="http://www.w3.org/1999/xhtml" lang="en-US"
   xml:lang="en-US" xmlns:svg  = 'http://www.w3.org/2000/
   svg-20000303-stylable'>
   <head><title>random</title>
   <body>
   <p>This is an HTML paragraph  with a mysterious SVG path in it.
   <svg:path d="M 80 75 L 100  100 L 140 110 z"/></p>
 </body></html>

Perhaps the browser will draw the path within the paragraph block, or perhaps it will ignore it. If the browser draws the path, does it start at the end of the paragraph's text content? Or does the browser treat the paragraph block as its natural container and use that as its starting point? While the semantics of an HTML p element and an SVG path element are well understood in their "home" contexts, dropping them into other contexts strips them of some of their meaning. XHTML 1.0 already recognizes this to a significant extent, although it includes demonstrations of how mixing and matching vocabularies might work. The conformance rules for strictly conformant XHTML documents (in section 3.1.1) require the use of document type definitions and demand that the document must validate against the formal description that DTD provides. While the examples that immediately follow (in section 3.1.2) show a non-conformant document, the W3C makes clear that "Future work by W3C will address ways to specify conformance for documents involving multiple namespaces."

XHTML 1.1 is effectively that future work. The next few articles provide the details of how XHTML sorts out context and processing, describing how XHTML 1.1 fragments itself into smaller pieces and how you can create your own pieces to add to the mix. First, though, let's take a detour to explore some issues that haven't been resolved yet – but which will need fixing for these visions to succeed.