information architecture · innovation & new stuff · interaction design

XHTML2 and XForms (an unusual kind of post for a blog like this)

Steven Pemberton

I’m going to go out on a limb now and talk about technical stuff that I don’t really know heaps about, but I think is really interesting for Information Architects and Interaction Designers. I hope that people of a more technical bent will chip in and correct any errors I make and fill in any gaps I’ve missed!

This post was inspired by what I think was the most intriguing presentation at the recent EuroIA conference in Berlin. This presentation was given by Steven Pemberton.

Now, Steven started his talk by breaking one of Kathy Sierra’s rules of presentations (don’t spend time telling people who you are and what you’ve done), but thank goodness he did, because I had no idea who he was or the amazing history that he has in shaping the web as we know it today.

Steven was sharing with a room full of Information Architects the joys of Xforms and XHTML2. A challenging task, given the range of backgrounds and expertise that Information Architects naturally have. Now… I know there were a few IAs with glazed over eyes, but for me… Steven’s talk held exciting prospects.

Let’s start with my take on Xforms.

Xform is short for XML Powered Web Form. The W3C says:

“XForms” is W3C’s name for a specification of Web forms that can be used with a wide variety of platforms including desktop computers, hand helds, information appliances, and even paper.

When talking about Xforms, advocates use great terms such as: open, interoperable, accessible, interoperable. The other thing they talk about is that you don’t need JavaScript and that it takes a fraction of the time to develop as compared with alternative technical approaches. We love the sound of this so far.

An XForms fan on the W3C website says that XForms are:

truly interactive, bi-directional Web of Applications, boosting structured interchange of information world-wide. This infrastructure standard significantly lowers development costs and total cost of ownership across all vertical, service and application-oriented web products – from e-commerce to e-goverment, e-finance to personal web communication.

So, in laymans terms (by my interpretation) what does this mean?

It means that we can design smart and more usable forms without having to use JavaScript (which we often can’t) and without increasing development time.

So, for example, address forms are only shown if the user indicates that they want or need to complete address details. If a form calls for partner/spouse information, these are only shown once a user indicates that they have a spouse or partner. So users only see the fields that they indicate they need to see. All users don’t have to see all forms.

Simpler forms. Less errors. Faster completion. All good.

How does this work technically? Well… unfortunately you’re at the wrong blog to work that out, but a quick look at Wikipedia (of course) shows you the downside that Steven didn’t really dwell on so much in his talk….

At the time of this writing, no widely used web browser supports XForms natively.

I don’t know much about Firefox 2.0 or IE 7.0, but from a quick review, it seems they’re into XForms. More’s the pity.

So why talk about Xforms?

Well… because they seem to me to be a great opportunity waiting to happen. And because if we don’t start talking about them and why we want/need them, then why will the browser manufacturers ever bother to support them?

Same, unfortunately, goes for XHTML2.

Steven’s talk got me all excited about the possibilities of XHTML2. It has a couple of key objectives including:

  • Less Presentation, More Structure – we all know that getting presentation OUT of HTML is a good idea
  • More Usability – for people who code, that is. Making HTML easier to write. That means making GOOD HTML easier to write. That’s a good idea.
  • More Accessibility – now, lots of people think that accessibility is boring or ‘out of scope for their target audience’ (that’s a whole other blog post). When Steven talks about accessibility he talks about ‘designing for our future selves’, when we all will have a shaky mouse hand and dodgy eyesight. Accessibility is boring whilst you’re young and agile, but you may live to regret thinking it too hard in the long term.
  • Better Internationalisation. Well… actually Steven says ‘internationalization’. I rest my case. (As an Australian this is a sore point, and there are sooooo many much worse off than I).
  • More device independence. Anyone who’s developed for multiple platforms would love this to be true… however, see above re: browser support, and then consider the nightmare that is mobile phones… even I think this may be optimistic. A great objective nonetheless.
  • Better Semantics. Now, this is the bit that I think is REALLY sexy :)

What does Better Semantics mean? Well, from what I understand it means that when I write ‘tomorrow’, it can actually mean 28 October 2006 without me spelling it out, and in a way that can be added to a calendar, or linked to other people’s ‘tomorrow’s’ that mean the same date, without me having to Google it and then link to ever single one. When I refer to a person, either by name or by a term like ‘the President of the United States’ I don’t need to explicitly explain who I’m talking about and then provide a link… but that potentially, all that additional information, or other information that I’ve already gathered, is available through that simple statement.

Now… even as I write that, I wonder how it would work. At this stage, I’m not inclined to trawl through the details, but the potential seems obvious.

As does the challenge for Information Architects. If we thought tags were problematic… then what kind of a challenge is this! How do we embrace the possibilities of a semantic version of HTML without unnecessarily constricting it OR compromising it through freedom? And, when and by whom are these semantic decisions made? By an IA, a designer or a coder?

Now, it’s completely possibly that I’ve entirely misintepreted both XForms and XHTML2. Afterall, you don’t come to this blog for the down and dirty on all things technical. But, based on what I heard from Steven, there are some interesting possibilities for the future that could be embraced sooner rather than later. And, no, this is nothing new. Afterall, Jeffrey Veen was lamenting XHTML2 and it’s lack of backward compatibility in 2003!

But I don’t live under a rock. And these things interest and potentially affect me. And I’ve not really heard much of them before.

I wonder if you’ve heard of/ been thinking of/ have an opinion on Xforms or XHTML2?

(And I very nervously hit Publish on a such-technically minded blog post…  If I’m completely off base… I blame Steven. Or Berlin!)

Image Credit: Michiel Hildebrand @ Flickr

14 thoughts on “XHTML2 and XForms (an unusual kind of post for a blog like this)

  1. Oh – forgot – yes I think XForms are a very interesting development, and I know Firefox (Mozilla) is working on their browser implementation (others, too, I have no doubt). XForms becomes most interesting when dealing with back-end data repositories – a lot of the field-level validation etc. can be happening in the browser rather than doing it a page at a time on the way to the data store.

  2. hey Ric, thanks for the tip re: Kurt. I’ll go check him out now!

    Yes, I forgot to mention that Xforms lets you do all that cool client-side form/page stuff that we now do with AJAX/JavaScript without the accessibility and other related issues that often make JavaScript a no-go zone, particular for large organisations.

  3. Leisa,

    I am glad that you are intrigued by XForms and XHTML 2! There is an aspect that I wish was not constantly overlooked, which is that you don’t need to implement XForms in a web browser to use it! Do you need PHP or Ruby or Python in your web browser to use these technologies to build web applications? Of course not! The same goes with XForms. You can use an implementation of XForms that runs on the server, yet allows you to have all the benefits of XForms, and more (including easy upgrades and more security).

    See for example our open source implementation of XForms at:

    and also this FAQ entry:


  4. Ric beat me to it. I was going to say Kurt Cagle was “the man” when it comes to explaining XForms.

    On the other hand – Elliot Rusty Harald is no slouch, and his terms in this post are nicely parallel with yours
    “Like XML before it, XForms is designed to separate intention from
    action, meaning from presentation. It’s designed to be a generic
    description of the input a form needs to collect. An XForm says little
    to nothing about how the form will be rendered or how the user will
    interact with it. The same form can be rendered one way in a browser,
    a different way in a phone tree with touchtone and voice-recognition
    input, and a third way on paper to be filled out with ink and scanned
    in using optical character recognition”

  5. ok. so… here’s what I’m still not sure of. Should we be doing anything with/about XForms and XHTML2 now?

    Should I be designing for the things that XForms can do and evangelising XForms, or are we not at that point yet?

    Should the IAs of the world be tackling the challenges including semantic content in code will bring to our world (like tagging all over again, but possibly crazier and more important to get right?)

    Is anything actually going to come of all of this, or is it the stuff of pipe dreams?

    Eh. And now I’m starting to obsess about MicroFormats… this is all getting very strange.

  6. I’d say XHTML1.1 + XForms1.0 is ready for use, XHTML2 may not be. I don’t know of many XHTML2 implementations but XForms has a few

    I personally am involved with the Mozilla XForms project and know that it has matured nicely in the past year. It passes almost 100% of the W3C test suite.

    1. ArmaninNa mez ognec haskanal bolor [email protected] internetum ashxatelis. Internetum haytni darnalu ev bisnes anelu hamar vochmiayn petqe imanal sayt stexcelu [email protected], ayl nayev ayn jisht [email protected], vorin menq qayl ar qayl tirapetel ev der tirapeteluenq [email protected]neri @ntacqum. Menq arajin ashkertnernenq, bayc mer [email protected] erbeqel chenq korcni @nker Armani het qani vor na misht patraste patasxanel ir bolor ashakertnerin huzox harcerin. Bolorin xorhurdem talis grancvel ev masnakcel [email protected] manavanq vor ayn dzez trvume anvjar, chapazanc harmaravet dzer isk tanic webinarneri mijocov ev [email protected] kapvumenq mimianc ev uraxanum mer [email protected] [email protected] ev hajoxutyunnerov` @nker Armani glxavorutyamb. Es husovem vor ays [email protected] kunena erkar ev kanach janapar qani vor ayn uni azniv npatakner. MAXTUMEM AMENALAVN U BARIN.Dzer dproci arajin ashakertneric` Bagrat ^_^

Comments are closed.