And these communities have all come to the HTML working group to ask for
new facilities.

XHTML2: The next generation in the X/HTML family

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.

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.

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.

Try to please as many people at once

Keep old communities happy

Keep new communities happy

Backwards compatibility

Earlier versions of HTML claimed to be backwards compatible with previous
versions.

For instance, 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.

The use of stylesheets

Structure

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.

Images

You might be surprised to know that <img> was not in the original
HTML.

<img> is actually badly designed:

Not backwards compatible :-)

No fallback except the alt text (this has seriously impeded the
acceptance of PNG images)

The alt text can't be marked up

Longdesc is hard to use, seldom implemented, and seldom used.

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>

Image types

HTML4 has the 'type' attribute in a number of places as a hint to the
browser as to what it could expect if it went and got a resource.

But it is pretty useless. Some browsers ignore it, some don't.

Now it is a specification of the type, and meshes with the HTTP accept:
field.

This means that

<p src="map" type="image/gif">...

will give you a GIF, or otherwise give you the fallback.

Similarly, you can write:

<p src="map" type="image/png, image/gif">...

or

<p src="map" type="image/*">...

Whitespace and pre

In HTML the only method to retain whitespace in content is with
<pre>.

IN XHTML2, all elements can use the attribute
layout="relevant".

<p class="poem" layout="relevant">
...
</p>

This doesn't impose a fixed-width font on the output, just that spaces and
newlines are preserved.

Lines

<br/> splits a paragraph into different parts, but they are
unaddressable with CSS.

So instead of a breaking element, XHTML2 uses a structuring element:

<p>Steven Pemberton<br/>
CWI/W3C<br/>
Amsterdam</p>

is now

<p><l>Steven Pemberton</l>
<l>CWI/W3C</l>
<l>Amsterdam</l></p>

This gives you many more presentational possibilities, such as automatic
numbering of lines, or colouring of alternate lines, etc.

Hypertext

In a non-backwards compatible step, HTML4 allowed any element to become
the target of a link (with id on any element).

XHTML2 extends this by now allowing any element to become the source of a
link as well, by allowing href anywhere.

So, instead of

<li><a href="http://www.w3.org/">W3C</a></li>

you may now write

<li href="http://www.w3.org/">W3C</li>

though <a> is still available.

Navigation lists

One thing you see everywhere on the web are menus for navigation,
implemented with script.

'property' gives the predicate for a string or XML fragment; the object is
in the element content (or the 'content' attribute).

'rel' gives the predicate for a URL: the object is in the href.

Generalising meta

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.

This work is licensed under the <a rel="dc:rights"
href="http://creativecommons.org/licenses/by/2.0/">
Creative Commons Attribution License</a>.

There is a standard filter called GRDDL for extracting the RDF from an
XHTML2 document.

Why this solution is nice

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.

The RDF community get their triples without RDF being imposed on the HTML
community.

Problems solved

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: an
element for <navigation>, an element for <note>s (in inline and
block versions), an element for lengths, and numbers, and ...

But first a diversion...

role

The accessibility community needed a way to specify what a particular
element was for.

Some examples: that a certain <div> was just a navbar, that another
<div> was the main content, etc. So 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">...

role values

In fact, anyone can add their own role values, so that whole communities
can agree on new semantics to overlay on to the content.

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">...

Access key

To go with the role attribute, there is a new way of doing
accesskey (which used to be spread through the document). Now in the
head you can say things like:

<access targetrole="main" key="M"/>

An advantage of this is that you can have different access keys for
different media.

There is also a targetid.

Events

Events in HTML are very restrictive:

the event name is hard-wired into the language, rather than being a
parameter, so that to be able to deal with a new sort of event you have
to add a new attribute, like onflash if an event called
flash were introduced.

the event name is usually very hardware specific, such as
click, when in fact you don't care how the button is activated,
only that is has been activated

you can only use one scripting language (since you can't have two
attributes called onclick, one for JavaScript and one for
VB)

event handling and markup are intertwined — there are no ways to
separate the two.

XFrames

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

The [back] button works unintuitively in many cases.

You cannot bookmark a collection of documents in a frameset.

If you do a [reload], the result may be different to what you had.

[page up] and [page down] are often hard to do.

You can get trapped in a frameset.

Searching finds HTML pages, not Framed pages, so search results usually
give you pages without the navigation context that they were intended to
be in.

XFrames (more)

Since you can't content negotiatiate, 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.

There are security problems caused by the fact that it is not visible
to the user when different frames come from different sources.

XFrames defines a separate XML
application, not a part of XHTML2 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.

There are already 2 implementations (XSmiles, DENG)

XForms: the new Web Forms language

HTML Forms: a great success!

Forms have been the basis of the e-commerce revolution

You find them everywhere on the web

Searching

Buying

Logging in

Configuring hardware

Reading mail

Composing email

Etc etc

Tracking packages

calculating currencies

submitting taxes

banking

expenses

calendars

blogging

wiki

...

So why XForms?

After a decade of experience with HTML Forms, we now know more about what
we need and how to achieve it.

Problems with HTML Forms

Presentation oriented, mixing data and presentation

No types, Ping-ponging to the server

Reliance on scripting

Problems with non-Western characters

Accessibility problems

Hard to make cross-device for single authoring

Impoverished data-model, no integration with existing streams

Hard to manage, hard to see what is returned

No support for wizards and shopping carts etc.

Soundbite: "Javascript accounts for 90% of our headaches in complex
forms, and is extremely brittle and unmaintainable."

XForms, the Approach and the Advantages

XForms has been designed based on an analysis of HTML Forms, what they can
do, and what they can't.

The Approach

The essence is to separate what is being returned from how the values are
filled in.

The model specifies the values being collected (the
instance), and their related logic:

Types, restrictions

Initial values, Relations between values

The body of the document then binds forms controls to
values in the instance

XForms improves the user experience

XForms has been designed to allow much to be checked by the browser, such
as

types of fields being filled in

that a particular field is required

or that one date is later than another.

This reduces the need for round trips to the server or for extensive
script-based solutions, and improves the user experience by giving immediate
feedback on what is being filled in.

It is easier to author and maintain complicated forms

Because XForms uses declarative markup to declare properties of values,
and to build relationships between values, it is much easier for the author
to create complicated, adaptive forms, and doesn't rely on scripting.

An HTML Form converted to XForms looks pretty much the same, but when you
start to build forms that HTML wasn't designed for, XForms becomes much
simpler.

It is XML, and it can submit XML

XForms is properly integrated into XML: it is in XML, the data it collects
in the form is XML, it can load external XML documents as initial data, and
can submit the results as XML.

By including the user in the XML pipeline, it at last means you can have
end-to-end XML, right up to the user's desktop.

However, it still supports 'legacy' servers.

XForms is also a part of XHTML2.

It combines existing XML technologies

Rather than reinventing the wheel, XForms uses a number of existing XML
technologies, such as

XPath for addressing and calculating values

XML Schema for defining data types.

This has a dual benefit:

ease of learning for people who already know these technologies

the ability for implementors to use off-the-shelf components to build
their systems.

It integrates into existing data streams

Data can be pre-loaded into a form from external sources.

Existing Schemas can be used.

It integrates with SOAP and XML RPC.

Doesn't require new server infrastructure.

It is device independent

Thanks to the intent-based controls, the same form can be delivered
without change to a traditional browser, a PDA, a mobile phone, a
voice browser, and even some more exotic emerging clients such as an Instant
Messenger.

This greatly eases providing forms to a wide audience, since forms only
need to be authored once.

It is internationalized

Thanks to using XML, there are no problems with loading and submitting
non-Western data.

It is accessible

XForms has been designed so that it will work equally well with accessible
technologies (for instance for blind users) and with traditional visual
browsers.

It is rather easy to implement

XMLDOMCSSJavascriptXHTMLXPathXForms

Â Â Â =Regular XHTML Browser

Time to build all of above: 3 programmers, 4 months

Total footprint (on IPAQ implementation): 400K (above Java VM)

In fact this is quite evolutionary: XForms uses existing W3C components.
It is only the XForms processing model that describes when to calculate
values that is really new.

Getting Initial Values From
Elsewhere

You don't have to specify the initial instance in the document itself,
because you can load it from an external resource, like this:

<instance
src="http://example.org/templates/t21.xml"/>

The resource then contains your data, like

<data>
<w>640</w>
<h>480</h>
<d>8</d>
</data>

You can use a local file, like
src="file:data.xml"

'Editing' any XML document

External instances give you immense power

The ref attribute on controls can be any XPath
expression

XPath lets you select any element or attribute in an XML document

You can bring in any XML document as instance, even an XHTML
document

... example

For instance to bind to the <title> element in an
XHTML document

<input ref="h:html/h:head/h:title">...

(i.e. the title element within the head
element within the html element, all in the XHTML
namespace)

or the class attribute on the body element:

<input ref="h:html/h:body/@class">...

Editing example

Suppose a shop has very unpredictable opening hours (perhaps it depends on
the weather), and they want to have a Web page that people can go to to see
if it is open. Suppose the page in question has a
single paragraph in the body: