Mark Birbeck, x-port.net, and Steven Pemberton, CWI/W3C, Amsterdam
These slides are in XHTML. They use the CSS media 'projection' to allow them to be displayed full-screen.
XHTML2 is the next version of the XHTML family, and is going to last call Real Soon Now. This presentation gives an overview of what XHTML2 is trying to achieve.
XHTML2 is the next iteration in the HTML family.
XHTML1 addressed the problems of turning HTML into an XML application.
XHTML2 addresses the remaining identified problems in HTML4/XHTML1
HTML: a great success, but has become a sort of Garden of Eden, with lots of Thou Shalt Nots in the form of guidelines:
etc, etc, etc
And these communities have all come to the HTML working group to ask for new facilities.
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. This means that it already works to a large extent in existing browsers (main missing functionality XForms and XML Events).
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.
Better forms: after a decade of experience, we now know how to make forms a better experience.
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.
Better semantics: integrate XHTML into the Semantic Web.
Keep old communities happy
Keep new communities happy
Everybody thinks they own HTML, and in a sense they do. WIth all these communities watching our work, we have a lot of coordination to do.
XHTML2 currently has more than 7500 recorded issues. And that is just one of the 10-ish specifications we look after.
And then there is the problem with trying to keep the browser manufacturer companies happy, who also think they own HTML.
New browsers will proclaim their standards adherence, but once they get their niche they start 'marking' behaviour, and want to make their own changes, and this has happened over and over again.
Part of the problem with every community wanting changes is that they don't understand the other communities needs.
Earlier versions of HTML claimed to be backwards compatible with previous versions.
For instance, in HTML4
<meta name="author" content="Steven Pemberton">
puts the content in an attribute and not in the content of the element for this reason.
In fact, the only version of HTML that is in any sense backwards compatible is XHTML1 (others all added new functionality like forms and tables).
XHTML2 takes advantage of CSS not to be element-wise backwards compatible, but 'architecturally' backwards compatible.
For instance, as mentioned already, much of XHTML2 works already in existing browsers.
XHTML2 is recognisably a family member:
<html xmlns="http://www.w3.org/2002/06/xhtml2/" xml:lang="en"> <head> <title>Virtual Library</title> </head> <body> <p><img src="vlib.png">[The Virtual Library]</img> Moved to <a href="http://example.org/">example.org</a>.</p> </body> </html>
One of the biggest problems for non-sighted people with many HTML pages is working out what the structure is. Often the only clue is the level of header used (h1, h2 etc), and often they are not used correctly.
To address this, in XHTML2 you can now make the structure of your documents more explicit, with the <section> and <h> elements.
<section> <h>A heading</h> ... <section> <h>A lower-level heading</h> ... </section> </section>
Advantages include:
h1-h6 are currently still available.
It is amazing how little issues can take so much effort.
A question that we often had to address was "is <hr> presentational?"
The Japanese community were also asking for a <vr>.
And then we had an aha moment...
These are all <hr>s! <hr> is not presentational, but structural: a lightweight section separator.
The only thing wrong with <hr> is that it is not (necessarily) horizontal, and not (necessarily) a rule!
We already needed a separator element for navigation lists, so we just decided to do away with all the confusion and rename <hr> to <separator>.
A paragraph is now much closer to what people perceive as a paragraph. For instance, this is now allowed:
<p>Advantages include: <ul> <li>easier to cut and paste and keep your heading levels consistent.</li> <li>importing sections in PHP-like situations</li> <li>you are no longer restricted to 6 levels of header.</li> </ul> </p>
You might be surprised to know that <img> was not in the original HTML.
<img> is actually badly designed:
So what we have done is allowed the src attribute on any element. The image replaces the element content, and the element content is fallback. Essentially we have added fallback, moved the longdesc into the document, merged it with alt, and allowed it to be marked up all in one go.
<p src="map.gif">Walk down the steps from the platform turn left, and walk on to the end of the street</p>
The img element is still available.
X/HTML has structure creating elements, like <p>, <h> and <div>, and textual elements, like <strong>, and <span>, and it has a smattering of elements and attributes that essentially add semantics or metadata:
etc. (as well as <meta> and <link> of course).
The HTML WG is constantly being asked to add new semantic elements, such as
and it often very hard to decide where to draw the line in adding new elements.
And furthermore, how do the existing semantics relate to the semantic web (i.e. to RDF), and how can you integrate XHTML into the semantic web (or RDF into XHTML) without sending the existing HTML community screaming in the other direction?
What we have done is craftily mutated <meta> and <link> so that they look more or less the same to the HTML author, but now have a clear relationship to RDF, and then generalised.
This was originally proposed in a white paper RDF/A (warning: details have changed since this was published), and after much work in a joint semantic web/HTML WG task force, was adopted into XHTML2 (that work is still not quite finished, since bnodes still have to be finalised).
<meta name="dc.creator" content="Steven Pemberton"/>
now becomes:
<meta property="dc:creator"> Steven Pemberton </meta>
The use of content
still permitted if you want:
<meta property="dc:creator" content="Steven Pemberton" />
<link rel="index" href="index.html"/>
now becomes
<link rel="index" href="index.html"/>
See the difference?
Both <link> and <meta> now also have an about
attribute, so that the metadata doesn't only have to be about the current
document any more:
<meta about="http://www.cwi.nl/~steven/" property="dc:creator"> Steven Pemberton </meta>
The default for about
is the current document (about="").
We can now say that <meta> and <rel> define RDF triples:
The attributes on <meta> and <link> can be used on any element. For instance:
<body> <h property="title">My Life and Times</h> ...
is a way of saying that "My Life and Times" is both the <title> of this document, as the top-level heading.
Similarly this records in an RDF-friendly way the license of the current document:
This work is licensed under the <a rel="dc:rights" href="http://creativecommons.org/licenses/by/2.0/"> Creative Commons Attribution License</a>.
(You'll note that this is nearly identical to the HTML idiom, but we can now relate it to RDF).
There is a standard filter called GRDDL for extracting the RDF from an XHTML2 document.
You can explain it using HTML concepts.
If you don't care, you can just ignore it.
It doesn't require you to learn how to use RDF to be able to benefit from it.
You can build up layers of semantics, and slowly add them to existing content.
The RDF community get their triples without the HTML community having to learn RDF.
This approach solves a lot of outstanding problems.
For instance, the Internationalisation community needed a way of adding
markup to a title
attribute.
Now we can just say that
<p id="p123" title="whatever">
is equivalent to:
<p id="p123"> <meta about="#p123" property="title">whatever</meta>
... and it solves the problem of everyone asking for new elements in XHTML. But first a diversion...
The accessibility community needed a way to specify what a particular element was for, for instance, that a certain <div> was just a navbar, that another <div> was the main content, etc. So at their request we introduced the 'role' attribute for this. You can now say:
<div role="navigation">...</div> ... <div role="main">...</div>
but once we had that mechanism, it allowed us to add any semantics we wanted, layering it on top of the structure. For example:
<p role="note">...
but also
<span role="note">...
<table role="note">...
In fact, anyone can add their own role values, so that whole communities can agree on new semantics to overlay on to the content. In fact this is exactly what microfomats are about.
Apparently the mobile and device-independent communities are very excited about the possibilities of using role.
In fact, you don't really need RSS anymore:
<h role="rss:title">... <p role="rss:description">...
HTML lets you say
<html> <head profile="...url..."> ... <body> ... <h3>News</h3> <ul class="news"> ...
Now you say
<html xmlns:hp="...url..."> ... <body> ... <h3>News</h3> <ul role="hp:news"> ...
Once a search engine can derive from the document that the text "the prime minister" means "Tony Blair", then a search for "Tony Blair" can find that page as well, even if it doesn't mention him by name, or a browser might offer additional information, for instance on hovering.
If the browser really knows that something is an address, it can offer to add it to your address book, or find it for you on a map.
If the browser really knows that something is an announcement for an event like a conference, and can identify the sub-parts, it can offer to add it to your agenda, find it on a map, locate hotels, look up flights, ...
In this talk I have only been able to scratch the surface of a handful of issues.
XHTML2 has been designed on the basis of requirements from a large number of different communities.
It has been designed to be as recognisably XHTML as possible within the constraints of the new requirements.
It is going to last call shortly: we welcome your comments!
Steven Pemberton: www.cwi.nl/~steven
These slides: www.w3.org/2005/Talks/05-steven-xtech