XForms Myths Exposed - By Ian Hixie (Opera)

Hello,

  Ian Hixie writes in the blog story titled "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
HTML1+XForms+XForms Actions+XPath to the exact
equivalent HTML4+JavaScript+DOM to see how it would
compare.

  More @ http://ln.hixie.ch/?start=1110316686&count=1

  What's your take? Do you think XForms "clean" design
is overhyped and it's "declarative" XML is just
super-verbose scripting in disguise?

   - Gerald   

_____________________________________
XUL News Wire - http://xulnews.com
XUL Alliance  - http://xulalliance.org

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

Received on Thursday, 10 March 2005 01:24:21 UTC