XHTML: The Great Integrator

Steven Pemberton

W3C/CWI, Amsterdam

XHTML: What's the point?

When XML was released, the question arose: do we still need HTML?

So we held a workshop, and the answer was 'yes': people like having a standard markup.

So we set out to define a family of XML-based markup languages: XHTML.

The Plan

• Clean up (get rid of historical flotsam)
• Return to structure only
• Use generic XML as much as possible
• Address wider needs (International, Accessibility)
• Modularise – split into separate parts

  Allows other XML applications to use parts

  Allows special purpose devices to use subset

• Add functionality (forms, better event handling, Ruby, ...)

The Approach

• HTML 4.01: corrected version
• XHTML 1.0: transitional version of HTML 4.01 in 3 flavours
• Modularisation: agreement on split and methodology
• XHTML Basic: Small devices, now part of WAP2
• XHTML 1.1: clean version of 1.0 strict
• XHTML 2: new functionality

The Advantages of Modularisation

XHTML adopted by WAP2

Modularisation used for the European Digital TV standard DVB MHP.

Several other modules now being produced externally.

XHTML+Math+SVG

XHTML+SMIL

Browsers now implementing XHTML, even down to the namespace level

New Functionality

• Events: accessible and device-independent
• Ruby: needed Asian markup
• Forms: more control
• Linking
• Frames
• XHTML 2.0: Putting it all together

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
• Author once

In fact as you will see, 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).

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

Less presentation

Remove all presentation-only markup.

Use stylesheets to define presentation.

Interoperability 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>

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

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

Interoperability advantage: more navigational possibilities.

Diversion: The Kiss of the Spiderbot

"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

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

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

A user agent has a default presentation.

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

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.

More information:

http://www.w3.org/Markup/

http://www.w3.org/Markup/Group/