What's Next for HTML?
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 |
