The "XForms Myth" Myth

It's great to see that someone who is well-known for being critical of XForms has finally written down in one place why they object to it -- it gives us something to respond to.

Hixie says on his blog, XForms myths:

I'm getting tired of hearing XForms advocates say things that are either misleading or clearly wrong, so here's a quick list of myths, or misleading truths, about XForms, which I have heard recently (most particularly during the multiple demos of XForms software at the plenary in Boston last week).

First let's set the scene; by "in Boston last week", Hixie means the W3C Technical Plenary where all the W3C Working Groups get together for a week. The middle day is usually given over to discussions and demos ... Lots of thought-provoking stuff.

The "multiple demos of XForms software" actually amounted to only two demos (perhaps it just felt like we were taking over, since I was also on a panel discussing the future of web applications, whilst Steven Pemberton, the chair of the XForms and HTML Working Groups, presented arguments for why we needed XForms rather than just tinkering with HTML).

The first demo was by me, in a section of what are called 'lightning talks' -- you get three minutes to talk about anything you like, and then the audience gets two minutes to ask you questions. It's a great format, and means that with good chairing (which Paul Downey ruthlessly provided!) you can squeeze 10 or so interesting topics into an hour. With my three minutes I demonstrated formsPlayer 2.0, with SVG widgets that sit on top of XForms, wired in using XBL.

The second of the 'multiple XForms demos' was in a different session, where the panel discussed voice-based systems. Mikko Honkala from the University of Helsinki showed X-Smiles running an XForm that allowed him to interact using speech. I don't think the audience quite appreciated the power of what they were seeing -- perhaps because Mikko's presentation did not look as polished as those from the multinational companies he was seated alongside -- but the form he was using to capture the voice data was exactly the same form that was used to capture keyboard input. In other words, XForms was showing its truly platform-independent nature.

So now you have the back-drop to Hixie's comments, let's go through his 'myths' one by one.

XForms is declarative

XForms is declarative
XForms has declarative aspects, just like HTML. But it isn't exclusively declarative. XForms in fact introduces a primitive XML-based scripting language (called XForms Actions) to perform imperative actions.

For example, you can use the setfocus element to set the focus to another element, or the load element to make the UA follow a link.

No-one said that XForms was exclusively declarative, and we certainly don't fall into the Microsoft XAML trap of saying that something is declarative just because it uses XML instead of code. So in that sense Hixie is right to point out that just using XML elements to define your actions does not make your language declarative.

But Hixie wins no points for saying that the non-declarative aspects of XForms are not declarative -- what he should really address is the truly declarative aspects of XForms, and say why he objects to them and would rather use spaghetti JavaScript in an attempt to achieve the same ends.

For example, in XForms we can indicate the range of possible values for a piece of data. We might say that the value must be a temperature above freezing. In the 'normal' programming model you achieve this functionality by checking at various points to see if the value entered is indeed above zero (and of course whether it is even a number at all). In an HTML form you might perform this check when the user changes the data, or just before you save the data to the server.

The key point is that how you do the checking is extremely likely to be different from how I do it, and when you do it will again be different from me. We can be pretty sure that we both used JavaScript since there is no other way to do it in HTML -- although we could have delegated the checking to the server -- but more than that we can't say. And if a machine looked at our HTML pages it would have trouble working out exactly which bit of script does the checking and when, since it would need to understand what the script was doing. (Try looking at the source for Google's Gmail or mapping site, and imagine writing an automated process that 'understands' what the code is doing.)

XForms provides a 'declarative' way to do this because it allows us to do everything that the HTML form can do, by doing nothing more than indicating what 'type' the data is. An XForms processor then takes care of the rest, including:

• sending notification events when the data changes from valid to invalid, or vice versa;


• changing the CSS to reflect the valid and invalid states;


• rendering alert messages when the data goes invalid.

And note that it does this automatically, as the data changes, interacting with all controls that are using this piece of data, something that gets very complicated in JavaScript when you get more than a couple of controls. But note also that XForms defines clearly when things happen, such as when the data is validated. This makes it much easier to write interoperable forms (forms that will run on many different XForms processors), since the flow is clearly defined in the spec.

In this example XForms is truly declarative, since we have not defined the 'how' of what we want doing, instead simply stating what it is we want to achieve.

Scripting is bad for accessibility

Scripting is bad for accessibility
False. Scripting doesn't hurt accessibility. What hurts accessibility is when semantically meaningless elements are given some sort of device-specific behaviour (for example, making a div into a checkbox or a scrollbar, or using the font element for headers).

I don't know anyone that doesn't think that scripting is almost completely useless for creating accessible applications. It is almost impossible to know which part of the script in a page is responsible for hints and captions, which therefore makes it difficult for voice systems to know what to read to a blind user, and when.

Script is harder to maintain than XPath expressions

Script is harder to maintain than XPath expressions
False. It depends entirely on what you're doing. The reason most JavaScript on the Web is a mess is because it is badly written; the same would happen to XPath if the same authors used that instead.

I haven't heard this myth, and I doubt Hixie has either, since it's like comparing apples with pears. XPath expressions are used in many different places, so in and of themselves they are not a replacement for scripting. Having said that, it is true that script is very hard to maintain.

But the most bizarre of Hixie's arguments is the statement that the script we see on the web is a mess "because it is badly written". I thought for a moment that Hixie might have finally understood why we need XForms, but that glimmer of hope passed, and Hixie settled comfortably back into his two-tier world of those that can work miracles with JavaScript and the rest of us (if you have the money and playtime that Google has, then sure you can build a passable email client and a map site with JavaScript ... But then given long enough I could dig a canyon with a teaspoon).

HTML mixes presentation and content -- XForms doesn't

HTML mixes presentation and content -- XForms doesn't
False. HTML doesn't mix presentation and content-- authors do. XForms doesn't prevent the two from being mixed, in fact one of the big things people are pushing these days is SVG+XForms, which is the ultimate mix of presentation and content.

There are quite a few things going on here, so let's prise them apart. The first is that 'authors' mix up presentation and content. Once again I thought I saw the lights going on, and once again the spark died. As before we have Hixie's two-tier world of those who follow 'best practice' and those who don't -- let's blame the author.

But he fails to ask why it is that authors are forced to mix presentation and content. It's not because they are not very good programmers, but the fact is that if you use JSP, ASP, ColdFusion, or any of the enormous number of server-side tools available to build your web-sites, you will have to mix up the UI with your data. For example, you will usually have to populate your list-boxes with data from your database by sticking some angle brackets and percentage symbols right into the heart of your code.

XForms takes a completely different approach -- you can load as many 'buckets' of XML into your form as you like, and you can then populate controls from that data. The UI really is separate from the data source. And you can go further; even the parts of a form that are normally regarded as static, such as hints, captions, help text, and so on, can be provided by some data server, rather than being poked directly into the form, on the server.

The second issue is that SVG+XForms is being pushed, and that this also mixes content and presentation. Whilst Hixie is right to warn of the dangers of mixing XForms and SVG, he missed the point of my demonstration. I was showing the Mozilla calculator running with SVG buttons -- but there was no SVG in the mark-up of the form. All the SVG was in separate XBL files, making it extremely easy to keep the specifics of the UI well away from the data. If the form was rendered on a system that did not have SVG installed, then the user would just see normal buttons. (I discussed skinning the calculator in a previous blog -- "On Calculators, Mozilla, SVG and XBL".

XForms is better than HTML because it is media-independent

XForms is better than HTML because it is media-independent
False. Both HTML and XForms are as media-independent as each other. If XForms is better it has nothing to do with one or the other being media-independent.

I don't really understand this.

HTML mainly specifies how the control should look, while XForms specifies what the control should do

HTML mainly specifies how the control should look, while XForms specifies what the control should do
False. HTML doesn't specify how the controls should look at all.

I think Hixie is being a little disingenuous if he implies that the HTML mark-up:

  <input type="radio" ... />
  <input type="checkbox" ... />

doesn't say something about how a control should 'look'. Of course it doesn't say whether it should be green or blue, but it does imply a certain way of interacting with the data -- check boxes and radio buttons -- whilst XForms is not so prescriptive.

HTML has limitations, so it had to be replaced with XForms

HTML has limitations, so it had to be replaced with XForms
False. It's easier to fix HTML than to replace it with an entirely new language.

Hixie needs to make his mind up ... Is the solution to fix HTML or to get programmers to write better script? The problem is either with the language or with the authors -- and if it is with the language then XForms is a pretty credible attempt to fix it (which is where XForms came from in the first place).

HTML requires authors to use hacks; XForms doesn't because is cleanly designed

HTML requires authors to use hacks; XForms doesn't because is cleanly designed
False. HTML doesn't require authors to use hacks, browser bugs do. And there's no reason to believe that XForms UAs will be any less buggy than HTML UAs, if it's the same programmers writing both UAs.

This is another odd one, but I guess we have to dive in. The hacks that authors use are not to get around browser bugs -- if only that were the case. The reason authors are forced to carry out hacks is because they are having to do things that HTML and JavaScript were never designed to do. Every day we see sites having to validate data and create clever pop-up solutions for help text and calendar widgets. But whilst the HTML programmer is messing around with mouseover events and scripting, the XForms author writes the following (declarative) mark-up:

  <input ref="sn">
    <label>Surname:</label>
    <hint>Please enter your surname</hint>
  </input>

Note that whilst the JavaScript hack has to rely on platform-specific features such as the mouse, our XForms mark-up does not rely on anything like that, which means that the same form functions just as easily on a voice system, as Mikko's demonstration so effectively illustrated.

That calculator again ...

To demonstrate some of these points, I took the XForms Calculator example, which was used as an example of some of XForms' power at the W3C Plenary last week, and made an HTML version.

I did use the Mozilla calculator in my demo, but it certainly wasn't for the purpose of demonstrating the power of XForms! Adding up a few numbers and stuff doesn't take a lot, and in fact as Hixie showed you can even do a simple calculator in JavaScript. My goal in using that particular sample was to take a form that had been authored by another XForms team, and show that it could be 'skinned' very easily with nice looking aqua buttons, an LED display, and a brushed metal background, without changing the 'logic' of their application.

(To see "XForms' power" we have far more advanced demonstrations, such as searching Amazon and Google, reading RSS feeds, accessing weather web services, and so on.)

Note that I didn't fix any of the bugs in the sample — there are a number of ways in which this demo is broken. I just converted the existing XHTML1+XForms+XForms Actions+XPath to the exact equivalent HTML4+JavaScript+DOM to see how it would compare.

Another example of Hixie's circular logic -- a language is devised that allows us to do things more easily, and he's surprised to discover that you can still do things the older, harder way! Anyway, what would be far more revealing would be for Hixie to take a much more substantial example, like the formsPlayer RSS Reader and convert that to HTML and JavaScript. I don't doubt that it's possible -- at least with a team of guys from Google with a month or two to spare, it probably would be -- but I can guarantee that we took less time than any scripter would (and less time than the C++ or Java equivalent, too).

What's more, the RSS Reader code is far more re-usable than any scripting equivalent would be; you could take our mark-up and completely change the user interface to suit your needs, something that would be pretty much impossible with the script version.

Conclusion

It's not surprising that XForms is raising hackles and ruffling feathers since it has the potential to displace a language that a lot of people have spent a lot of time learning and building businesses around. But just as I gave up assembler programming to use C, so I now gladly drop spaghetti-script for XForms. It's not perfect and there are plenty of new features that I would like to see introduced, but its most important role has been to demonstrate that we don't need to be wedded to the old approaches for ever, and that new solutions are possible, and here today.