XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.

advertisement

What's Next for HTML?

September 04, 2002

HTML has always been the predominant data format of the Web, and it has influenced the design of nearly every XML vocabulary ever written. So it's a little disappointing to see the languid adoption of XHTML, which takes HTML from its SGML heritage into the world of XML. Partly this is because XHTML 1.0 dealt only with the XML-specific mechanics of the transition, and version 1.1 addressed only modularization -- ways to combine bits and pieces of XML languages. Benefits associated with switching to XHTML 1.x are modest at best.

XHTML 2.0, in contrast, marks the beginning of a new phase of development for HTML. The key goal in version 2.0 is to factor away the accumulated baggage in the language while retaining the familiarity and simplicity that has always been associated with HTML. This means that the language will improve in ways that aren't backwards compatible. This article takes a deeper look at some of the new features in XHTML 2.0, based on the initial public W3C documents of XHTML 2.0 and XFrames, dated 5 and 6 August 2002 respectively, and the further developed XML Events and XForms 1.0 drafts dated 12 and 21 August 2002 respectively.

XFrames

The two biggest areas in need of improvement are forms and frames, both of which are now independent W3C specifications, which XHTML 2.0 includes by reference. Another article discusses the XForms 1.0 specification, which in XHTML 2.0 is completely replacing <form> and the associated patchwork of form-related tags. XForms was recently republished incorporating Last Call public comments and shortly will move to the Candidate Recommendation phase to build implementation experience.

The XFrames specification replaces the <frameset> element, which was removed entirely from XHTML 1.1. XFrames is actually a new document type, and not a part of XHTML itself; it can be used with XHTML, SVG, or nearly any other web language. The concept is simple: an XFrames document defines only the basic description of how to compose multiple documents into a single view, like this example with a row containing two columns:

<frames xmlns="http://www.w3.org/2002/06/xframes">
  <style> ... </style>
  <row>
    <frame id="navigation"/>
    <frame id="main"/>
  </row>
</frames>

Each <frame> may contain a default URI, but in general, deciding what to render in each frame is accomplished by a special URI fragment syntax, with a mapping from each frame to a relative or absolute URI. For example:

http://example.info/#frames(navigation=nav.svg,main=main.html)

The great thing about this design is that framesets are fully bookmarkable, the "back" button in browsers will work as expected, and it's harder for sites to "framejack" (use frames to represent someone else's content as their own), since the URLs are more visible. Details, like the sizes and borders of the frames, are all defined in a style sheet language such as CSS. The specification makes a point of not limiting the presentation to ordinary non-overlapping frames seen on the Web today. For instance, each frame could be a movable window-like page, or a set of tabs -- again under control of a style sheet. To encourage this kind of separation, the XFrames language includes a <style> element to contain the not-yet-specified CSS that can control such presentation details.

XML Events

Another, more general problem in markup languages is the proliferation of scripting and event-specific syntaxes. For example, a typical HTML interface to a search engine might include code like this (while SVG and SMIL have similar but incompatible syntaxes):

...
  <head>
    <script><!-- 
      function init()
      { document.frm.query.focus();} 
      // --></script>
  </head>
  <body onload="init()">
  ...

For one thing, this requires a specific attribute onload to be part of the HTML language, so any change to the event model would require a change to the language. Worse yet, it's awkward to describe what scripting language should be used to interpret the attribute. And why should script be needed at all for such a simple function?

XML Events addresses all of these problems with a declarative syntax that builds directly on DOM Level 2 Events. In this system, every event begins at the root of the DOM tree and "propagates" to a particular target node in a process called the "capture phase". Any node in the line between the root and the target can act as an "observer", which can trigger declarative actions (including script), stop the event from continuing, or block the default action of the event. An additional phase, called the "bubbling phase", occurs after the event reaches the target and returns to the root node. In many cases, however, the interesting things happen right at the target element, and thus both the capture phase and the bubble phase can be ignored.

In the search engine example, the "load" event makes its way to the <body> target node. A "handler", such as <xforms:setfocus>, can cause some action to occur in response to the event. The following example shows this:

...
  <xforms:setfocus control="query" id="focus_handler"/>
  ...
  <listener event="load" observer="body_id" handler="#focus_handler"/>
  ...
  <body id="body_id">
...

(Note: The initial draft of XHTML indicates the presence of the <listener> element, as well as XForms elements, but doesn't indicate where the elements are allowed.)

XML Events also defines various defaulting scenarios, using "global attributes", that alleviate the need for a separate <listener> element. The events attributes can be placed on the observer element:

<body ev:event="load" ev:handler="#focus_handler">

Or on the handler element:

<xforms:setfocus control="query" ev:event="load" ev:observer="body_id"/>

In cases where the handler is a child element of the observer, then the only needed attribute is ev:event, a pattern that is frequently used in XForms. No matter what the syntax, the ability to use declarative markup instead of scripting is a welcome change for anyone who has had to write or maintain web pages, and the end result works much better in non-visual browsers and accessibility tools.

At the time of writing, one piece that is still missing is a promised Part 2 of XML Events, which will define specific event handlers to replace many common uses of script. Future versions of SVG and SMIL will probably use both the XML Events framework and the common handlers.

Pages: 1, 2

Next Pagearrow