What's Next for HTML?
by Micah Dubinko
|
Pages: 1, 2
Changes to XHTML
Changes to the main language in XHTML 2.0 have been covered previously on XML.com (in an XML-Deviant column, "XHTML 2.0: The Latest Trick"). Still, it's interesting to look for patterns in the changes so far:
<section>and<h>elements- This design favors structural markup that encloses an entire logical unit, rather than
<hn>elements that just mark the boundaries. This nudges authors in the direction of more meaningful markup. - Navigation Lists (
<nl>) - Declarative navigation single-handedly can remove the need for scripting from millions of web pages. This will be a huge win for producers and consumers alike.
<applet>and<img>removed in favor of<object>- HTML specifications have been
suggesting this
for a number of years, and now it's official. The
<object>element is more capable than the alternatives it replaces, for instance allowing multiple levels of fallback, and removing two unnecessary elements simplifies the language.
The aspect of XHTML 2.0 that has gathered the most attention (and which
was reviewed in a recent XML-Deviant column, "The Absent Yet
Present Link") is something that is unchanged from the earliest
versions of HTML: the use of href for hyperlinks, rather than
the different, incompatible syntax recommended by XLink. This has
come to the fore in XHTML 2.0, since backwards compatibility is less of a
goal, and since linking attributes are proposed to be added to almost
every element. The HTML Working Group has promised to release information
on the technical reasons for this approach, as part of a specification
that has come to be called "HLink". A future article will take a look at
HLink, XLink, and their relationship to XHTML.
Using XHTML 2.0 Today
Modern browsers, including Internet Explorer, the Mozilla family, and Opera, have been moving toward universality, providing hooks for generic XML processing rather than using hard-coded semantics of HTML. Sjoerd Visscher has capitalized on this, providing a demonstration of XHTML 2.0 on current browsers. His implementation uses a combination of behaviors on Internet Explorer, XBL on Mozilla, and special linking styles on Opera.
Sjoerd also has done some good work on an XSLT converstion of XHTML 2.0 into something renderable on both Mozilla and IE.
Browser vendors are beginning to release information on their plans to support XHTML 2.0 and family. Opera has been working on an improved layout engine, which their standards engineers claim will support XHTML 2.0 by the time it becomes a W3C Recommendation. The Mozilla project has feature requests for XHTML 2.0, XForms, XFrames, and XML Events. Interested parties can register their desire for these features to be implemented by visiting these links and clicking on "vote for this bug".
Future Directions
While XForms and XML Events are more or less fully developed, so far only the initial Working Drafts of XHTML 2.0 and XFrames have been released. It's natural to wonder what kinds of changes are still in store. Based on a large amount of activity on the public www-html mailing list, a few topics that have been proposed are:
- Whether to allow lists and
<object>to have a caption. - Whether to use RDF or a simpler RDF-compatible format for metadata.
- Possible new elements
<number>,<notice>, and<footer>. - Whether or not to keep
<hr>, and whether it is presentational or semantic in nature. - Whether to allow
<title>within the body section.
While it may not make it into the official specification, Masayasu Ishikawa has posted some unofficial RELAX NG schemas for various XHTML 2.0 modules.
The ultimate outcome of each of these issues is in the hands of the HTML Working Group. They welcome feedback and discussion on the www-html mailing list. (This is a subscription list. To subscribe, send an initial message to www-html-request@w3.org with the subject "subscribe"). A new roadmap shows the estimated time frame for the different pieces of the HTML family.
What You Can Do
The question on everyone's mind is whether XHTML 2.0 has any chance at widespread adoption, especially since XHTML 1.x still isn't properly implemented in mainstream browsers. The two basic approaches to evolving a markup language are to maintain backwards compatibility or to make a clean break. Till recently the W3C has explored the compatibility approach to the limits. The result has been a document format that has costs associated with switching to it, but relatively limited benefits. By making improvements without the shackles of strict compatibility, XHTML 2.0 is now able to provide enough benefit to justify the cost of switching.
Maybe.
The main disadvantage of the clean break approach is the resulting chicken-and-egg problem -- if no browsers support XHTML 2.0, why write web pages in it? And if there's no web pages written in it, what incentive do browser vendors have to support it? Both of these questions need to be addressed.
As this article has shown, XHTML 2.0 isn't that incompatible with modern browsers, which are already flexible enough to handle much of XHTML 2.0. (In fact, this article was written, prepared, proofread, and distributed in XHTML 2.0 format.) The prospect of clean, declarative markup over custom-written scripting and other hacks gives webmasters ample motivation to begin experimenting with XHTML 2.0 and to start asking their favorite browser vendor when they will natively support the standard.
From a growing murmur of discontent with HTML 4.x and XHTML 1.x, it's clear that demand for better client-side web solutions is building to a critical level. Will this need be filled with an open standard like XHTML 2.0, or will a closed proprietary solution fill the gap? This will be a key question over the next year. The answer will depend in part on the choices you make.
- How to get XHTML 2.0 into wide use
2002-10-16 14:35:09 Mark Shepherd
