XHTML, XForms and Device Independence

Steven Pemberton, CWI, Amsterdam and W3C

Chair, W3C HTML and Forms Working Groups

HTML: A success!

No one can deny that HTML has been a great success. But...

It is a mess. Both in its design and its use.

XHTML is trying to improve the situation.

XHTML

XHTML is a family of XML-based markup languages.

Currently:

• XHTML 1.0 (in 3 flavours): HTML 4 in XML. A transition strategy.
• XHTML 1.1: A cleaned-up XHTML 1.0 Strict
• XHTML Basic: For small devices. Now a part of WAP 2

XHTML 2

We are currently working on a new member of the XHTML family, in our minds the 'real' XHTML.

Our aims are:

• As generic XML as possible
• Less presentation, more structure
• More accessibility
• Less scripting
• More usability
• More device independence

In fact as I will show, many of these things are intertwined.

Generic XML

By 'generic XML' we mean: if a facility exists in XML technologies, and it is suitable, use it and not a special-purpose XHTML facility. Try to get missing functionality added to XML.

Examples:

• All presentation defined in terms of CSS
• All presentation tags removed
• CSS being updated for missing functionality
• xml-base added to XML to replace <base>

Major missing functionality: Linking (XLink insufficient for XHTML's needs).

Device independence advantage: the generic features have been designed without reference to devices.

Less presentation

Remove all presentation-only markup.

Use stylesheets to define presentation.

Device independence advantage: possible to author once, and display on different devices; better presentation possibilities; device presentation not hardwired; CSS has support for devices

Power of CSS currently seriously underappreciated.

(Note: doesn't require CSS to be implemented; just uses its model)

More structure

Add more semantically-oriented markup to make documents richer.

Examples: <line> element instead of <br>. <section> and <h> elements instead of <h1> <h2> etc

Not

I think that I shall never see<br>
A poem lovely as a tree

but

<line>I think that I shall never see</line>
<line>A poem lovely as a tree</line>

Device independence advantage: more presentational opportunities (folding, marquee)

More accessibility

This largely falls out automatically from other aims.

For instance <h1>, <h2> etc are mostly terrible for accessibility, because no one uses them right, and it is hard to work out document structure from so little information.

Structure/Accessibility example

<h2>Chapter 1</h2>
...
<h3>Section 1</h3>
...

is now:

<section>
<h>Chapter 1</h>
....
   <section>
   <h>Section 1</h>
   ...
   </section>
</section>

More structure gives more accessibility. So does device independence.

Less scripting

Observe how scripting is currently used.

Identify missing markup/functionality.

Add it where possible; try to cover 80% mark

Examples: menus for navigation; forms data checking; folding presentation.

Device independence advantage: less scripting, more presentational variations

More usability

Research has shown that usability is the second most important property of a website.

As an example of poor usability, current frames are a disaster!

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

Usability of frames [continued]

• Search engines find HTML pages, not Framed pages, so search results usually give you pages without the navigation context that they were intended to be in.
• Since you can't content negotiatiate, <noframes> markup is necessary for user agents that don't support frames. Search engines are 'user agents' that don't support frames! But despite that, almost no one produces <noframes> content, and so it ruins web searches.
• There are security problems caused by the fact that it is not visible to the user when different frames come from different sources.

Currently devising a replacement for Frames.

Device-independence advantage: more navigational possibilities.

Diversion: arachnophobia

"Google is, for all intents, a blind user. A billionaire blind user with tens of millions of friends, all of whom hang on his every word. I suspect Google will have a stronger impact than [laws] in building accessible websites."

...

"In a world where Google likely has a valuation several orders of magnitude higher than any chrome such as flash, graphics, audio, interactivity, or "personalization", I see a heady revision."

Karsten M. Self

Spider traps

• Sites with no content (e.g. Flash), no <noframes> content
• Java/Javascript dependencies.
• Obviously CGI-driven sites (bots avoid these as they tend to be spider traps)
• Session-ID'd URLs.
• Audio content (not searchable)
• Text-as-graphics. Google handles a number of formats, but it doesn't OCR.
• Changeable sites. The longer you stay in one place, the better your Google score. Don't move content!

More device independence

Less scripting

No hard-wired presentation

Events

New Forms

Events

Current HTML events are a disaster

• For device independence
• For accessibility
• For authoring
• For document repurposing

Problems include:

• Device properties are encoded (e.g. onclick)
• Document structure and scripting are entwined rather than separated out
• Scripting language is hard-wired in document.
• Can't add new event types

XML Events

XML markup binding to DOM2 Events

Extensible for new event types

'Abstract' events can replace the old device-dependent ones (e.g. 'activate' instead of 'click')

Independent of scripting language

Can entwine event markup in document, or can separate it out

Device-independence advantages: more types of events, other types of scripting (e.g. declarative)

<a onClick="...javascript..." ...>

becomes

<a ev:event="activate" ev:handler="#myhandler" ...>

XForms

HTML forms have proven their worth.

XForms improves this:

• Client-side checking (no scripting)
• More data types
• XML instance is returned
• Form controls markup is separated from data-types and returned values

Essentially defines two separate parts: the 'real' form (data, datatypes and submission details), and form controls bound to the data.

A language may define its own set of form controls.

XForms 'native' form controls are device-independent, and accessible.

Example Form Control

<input ref="order/shipTo/street">
  <caption>Street</caption>
  <hint>Please enter the number and street name</hint>
</input>

A user agent has a default presentation.

If the user agent supports it, a stylesheet can be used to define other presentations.

Another example control

<select ref="my:icecream/my:flavors">
  <label>Flavours</label>
  <choices>
    <item><label>Vanilla</label><value>v</value></item>
    <item><label>Strawberry</label><value>s</value></item>
    <item><label>Chocolate</label><value>c</value></item>
  </choices>
</select>

This example covers both radio-button style selection, and menu selection: not encoded in the control.

Conclusions

HTML was originally designed as a structure description language, not a presentational language.

The design of XHTML is truly 'radical': taking HTML back to its roots.

Device independence and accessibility are surprisingly closely related (as are accessibility and usability)

Even though website builders may not yet know it, device independence, accessibility and usability have a major economic argument in their favour.