XHTML and XForms
Slides by Steven Pemberton, CWI, Amsterdam and W3C
(original here)
Additional errors inserted by Micah Dubinko, Brain Attic, L.L.C.
The XHTML Family
XHTML is a family of XML-based markup languages being designed.
Currently it consists of:
- 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 mobile phones, as well as soon for printers and TVs - And soon: XHTML 2
Example of XHTML running on a phone
XHTML 2
The new member of the XHTML family is in our minds the real XHTML.
Our aims are:
- As generic XML as possible
- Less presentation, more structure
- More usability
- More accessibility
- Better internationalization
- More device independence
- Less scripting
In fact, many of these things are intertwined.
Aim: 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.
Advantages: less variability; more interoperability; much of XHTML 2 works already; opportunity to make a cleaner break.
Aim: Less presentation
Remove all presentation-only markup.
Use stylesheets to define presentation.
Advantages: possible to author once, and display on different devices; better presentation possibilities; device presentation not hardwired; CSS has support for devices; more accessibility.
The power of CSS is currently seriously underappreciated.
(Note: doesn't require CSS to be implemented; just uses its model)
Aim: More structure
Add more semantically-oriented markup to make documents richer.
Examples: <l> 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
<l>I think that I shall never see</l> <l>A poem lovely as a tree</l>
Advantages: more presentational opportunities (folding,
marquee, numbering)
[More shortly]
Aim: More usability
Forrester Research did research on why people go back regularly to some sites and not others. They found only 4 important reasons:
- Good content (75%)
- Usability (66%)
- Speed (58%)
- Frequency of updating (54%)
(the rest is noise: 14% and lower)
More usability for: the author, the surfer
As an example of poor usability, current frames are a disaster! We are currently defining XFrames, a replacement for Frames.
Aim: More accessibility
One day we will all be grateful for accessible websites. Maybe even today.
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."
Karsten M. Self
Examples: more structure, navigation lists, better reatment of images
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.
Images
In designing XHTML 2 we decided to do away with a separate concept of an image altogether. Now we just say that there is an equivalence between an external resource and an internal one. For instance
<table src="temperatures.png"> <caption>Average monthly temperatures</caption> <tr> <th>Jan</th> <th>Feb</th>.... <tr> <td>0</td> <td>-4</td>... </table>
A browser that can do images will display the image; others will display the table.
Advantages: device independence, accessibility, and even usability (since if the image is unreachable the document is still useful.)
Aim: Internationalization
- Largely thanks to generic XML facilities
- But: Ruby markup for East-Asian texts
- Less use of text-in-attributes (like alt), that cannot be marked up.
Aim: 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.
Advantages: more devices, more presentational variations, better search, better accessibility
Aim: More device independence
With an aim to single authoring
E.g.
- Less scripting
- No hard-wired presentation: a document can be styled with different stylesheets for different devices (as supported by CSS2)
- Events
- Forms
Current HTML events are a disaster
- 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 events)
XML Events addresses these.
<a onClick="...javascript..." ...>
becomes
<a ev:event="activate" ev:handler="#hdlr" ...>
Linking revisited
- Any element can be an outgoing link, just add href
- www-128.ibm.com/developerworks/library/x-xhtmlnk.html
- Additional goes-anywhere attributes: hreflang, hreftype, cite, access, target, xml:base
Navigation Lists
No more pressing forms into service for navigation!
<nl xml:base="http://xformsinstitute.com/essentials/browse/"> <label>Table of Contents</label> <li href="ch01.php">Introduction to Web Forms</li> <li href="ch02.php">XForms Building Blocks</li> <li href="ch03.php">XPath in XForms</li> ... </nl>
Inclusion Revisited
- Two kinds of linking: href and src
- src can go anywhere, replacement or fallback semantics
- Forcing authors to think about fallback = more accessibility
Rethinking Metadata
- Two exisitng elements: meta, and link
- meta is for statements ending with text, like
<meta property="keywords">vacation, Phoenix, sunshine</meta>
- link is for statements ending with a URL, like
<link rel="identifier" type="text/plain" resource="http://rfc.org/rfc3236.txt"/>
- Can go anywhere in document, not just in the head
- Can be chained, for statements about other subjects, like:
<link rel="dc:copyright" resource="http://www.bbc.co.uk"> <meta property="dc:location">London</meta> </link>
XForms
- Client-side checking, datatypes (no scripting)
- XML data is returned
- Form controls markup is separated from data
- Controls are device-independent and accessible.
- Two parts: the 'real' form (data, types, submission detail), and controls bound to data.
The Model
The Model contains a number of things:
- instance(s)
Data that is being used, manipulated, and/or submitted by the Form
May be in the XForms document, or external.
Any XML document
- Schemas
Data types can be checked on the client; better usability, less trips to the server.
The Model (more)
- Bindings, constraints, calculations on and between instance data
Values can be calculated without resorting to scripting
- Details of how to submit
Submission is as an XML document (plus legacy formats)
The User Interface
The User Interface binds into data in an instance.
- Uses XPath to bind
- Means there is no need for 'hidden' UI controls
The XForms set of UI controls are abstract controls, representing the intent of the control, not its look. You can then use CSS etc., for generating a presentation.
This means (amongst other things) that you can generate different presentations for different devices from the same form.
Control Example
For instance a select1 represents the notion of selecting a
single value from a list. It can then be rendered as
- Radio buttons
- Select list
- Drop down/pop up menu
- (or anything else you can come up with)
You can even use different presentations for different devices.
XForms Demo
XForms is a W3C Recommendation, with a large number of complete and in-progress implementations.
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, accessibility and usability are surprisingly closely related.
Even though website builders may not yet know it, device independence, accessibility and usability have a major economic argument in their favour. Spread the word!