Steven Pemberton, CWI, Amsterdam and W3C
Chair, W3C HTML and Forms Working Groups
Media type
XHTML Modularization
XHTML Modularization in XML Schema
Profiles, Schemas, Notes, Test Suites, Errata
Modularization second edition: awaiting XML Schema second edition
XHTML-Print: Now in CR
XFrames
XML Handlers
XHTML2
HTML Frames create several usability problem that caused several commentators to advise Web site builders to avoid them at all costs. Examples are:
noframes
markup is
necessary for user agents that don't support frames. However, almost no
one produces noframes content, and so it ruins Web searches, since search
engines are examples of user agents that do not support frames.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)
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)
"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)
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.
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.
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).
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: 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
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.