HTML Technical Review

Steven Pemberton, CWI, Amsterdam and W3C
Chair, W3C HTML and Forms Working Groups

Overview: Work completed

HTML 4.01

XHTML 1.0, 1st & 2nd ed

XHTML 1.1

XHTML Basic

XML Events

Media type

XHTML Modularization

XHTML Modularization in XML Schema

Profiles, Schemas, Notes, Test Suites, Errata

Work nearing completion

Modularization second edition: awaiting XML Schema second edition

XHTML-Print: Now in CR

Work to be finished

XFrames

XML Handlers

XHTML2

XFrames

HTML Frames create several usability problem that caused several commentators to advise Web site builders to avoid them at all costs. Examples are:

XFrames (more)

XFrames defines a separate XML application, not a part of XHTML per se, that allows similar functionality to HTML Frames, with fewer usability problems, principally by making the content of the frameset visible in its URI.

Already have 2 implementations (XSmiles, DENG)

XML Handlers

This is part 2 of XML Events.

XML Events defines the binding between event, DOM tree and handler, without specifying exactly what a handler is. This was deliberate, since several existing specs already had event bindings, and by splitting the spec into two it allowed specs to transition more easily.

But now people are clamouring for part 2, that defines handlers. This is particularly being called for by browser builders, like Mozilla, XSmiles, DENG.

(Others, for instance WAI, DI, XForms, SVG, are clamouring for even more: a standard set of device independent events, a binding to DOM manipulation APIs, and namespaced event bindings)

XHTML2: "the one bright light"

"Simple functionality and common sense appear -- at least temporarily -- to have triumphed over byzantine theological imperatives."

"Is this a bright and shining star? I think so."

Already works to a large extent in existing browsers (main missing functionality XForms and XML Events)

Being adopted by Oasis Legal XML group ("You had already solved all our ptoblems)

XHTML2

In designing XHTML2, a number of design aims were kept in mind to help direct the design. These included:

As generic XML as possible: if a facility exists in XML, try to use that rather than duplicating it.

Less presentation, more structure: use stylesheets for defining presentation.

More usability: within the constraints of XML, try to make the language easy to write, and make the resulting documents easy to use.

More accessibility: 'designing for our future selves' – the design should be as inclusive as possible.

XHTML2 (more)

Better internationalization.

More device independence: new devices coming online, such as telephones, PDAs, tablets, televisions and so on mean that it is imperative to have a design that allows you to author once and render in different ways on different devices, rather than authoring new versions of the document for each type of device.

Less scripting: achieving functionality through scripting is difficult for the author and restricts the type of user agent you can use to view the document. We have tried to identify current typical usage, and include those usages in markup.

Working method

Based on identified shortcomings of HTML (usually as a result of coordination), try to solve each problem in as simple and XML-like manner as well, while trying to keep the HTML community happy.

Where solutions are more widely applicable, separate them into separate specs. A major example of this is XML Events. (Another is XFrames).

XHTML2: Coordination

The HTML WG has an immense list of groups for coordination. Examples:

Semantic web: better integration with RDF through meta and link

Internationalization: Ruby, bidi, whitespace

Accessibility: access[key], navigation lists, img, longdesc, role attribute, XML Events

CSS: media types, whitespace

DI: img, XML Events, role

XHTML2 status

XHTML2: putting it all together: RDF stuff, XForms, accessibility stuff, DI stuff, XML Events...

Plan to go to last call this month.

Remaining small amount of work to do: access[key], role attribute, whitespace preservation, improve description of relation to RDF

Problem area: media type

How do you identify different profiles via the media type?

WAP2: uses a parameter

XHTML Print: was planning a completely new media type

Profiles: XHTML2+SVG, XHTML2+SMIL etc.: how should we do it?

One suggestion has been to add a parameter that lists the DOM hasfeature strings of the (compound) document.