log_e.hixie.ch

2005-03-08 21:18 UTC 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).

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

<xf:toggle case="add"/>

operation = add;

<xf:action ev:event="DOMActivate">...</xf:action>

onclick="..."

<td>
 <xf:trigger>
  <xf:label>9</xf:label>
  <xf:action ev:event="DOMActivate">
   <xf:setvalue ref="/equation/displaybuffer"
                value="/equation/displaybuffer * 10 + 9"/>
   <xf:setvalue ref="/equation/display"
                value="/equation/displaybuffer"/>
  </xf:action>
 </xf:trigger>
</td>

<td>
 <button onclick="display = displaybuffer
                          = displaybuffer * 10 + 9; update();">
  9
 </button>
</td>

Pingbacks: 1