W3C home > Mailing lists > Public > www-forms@w3.org > March 2005

RE: XForms Myths Exposed - By Ian Hixie (Opera)

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 13 Mar 2005 17:22:13 +0000 (UTC)
To: Mark Birbeck <mark.birbeck@x-port.net>
Cc: www-forms@w3.org
Message-ID: <Pine.LNX.4.61.0503131621450.13434@dhalsim.dreamhost.com>

On Fri, 11 Mar 2005, Mark Birbeck wrote:
> > 
> > The progression, IMHO, is really between the generally high skill set 
> > of your average XForms author and the comparatively low skill set of 
> > your average HTML author.
> 
> XForms caters to both -- it allows you to do very powerful things more 
> easily, as well as very simple things more easily (more on that, below). 
> It is much more powerful than HTML+JavaScript, yet does it with clean 
> mark-up.

You missed my point, which was that IMHO the reason most current XForms 
documents are of a higher markup quality (more conformant, more 
accessible) than the average HTML document is that the average XForms 
author today is more competent than the average HTML author.

It has nothing to do with whether XForms is easy or hard.


> In some ways it is comparable to VB or even C++/C#/Java.

Indeed. Or Perl or PHP. Most PHP scripts I've seen are of a much lower 
quality of code than most C++ programs I've seen, but that's just because 
the C++ programmers tend to be simply more experienced programmers. Same 
with VB compared to Java -- VB programs tend to be of a lower quality 
merely because it is targetted at less experienced authors.


> WebForms 2.0 ... has tabs in the language

You may be thinking of some of the work-in-progress suggestions for Web 
Apps 1.0; WF2 doesn't mention tabs as far as I recall.


> > The reason, IMHO, that most XForms now is better in terms of 
> > accessibility is simply that the authors writing it are learning how 
> > to do it right. If XForms reaches a critical mass where authors from 
> > the "copy paste" line of work become prevalent, then accessibility 
> > will suffer as it did with HTML.
> 
> The previous mark-up shows pretty clearly that this is simply not the 
> case -- the accessibility benefits from XForms are built into the 
> language, and the whole reason for doing that was so that it would be 
> easy for the authors to add accessibility without even having to think 
> about it.

The accessibility benefits of HTML are built into the language too. That's 
irrelevant. For example, HTML has a perfectly adequate checkbox control, 
yet authors have been known to reimplement their own using <div>s and JS.


> Whilst you are right Ian, to say that the complicated applications that 
> you can produce with XForms will be out of the reach of the average HTML 
> programmer, I would say that you are wrong to imply that XForms raises 
> the bar for authors more generally.

All your examples used XHTML2, which is not even in last call yet (and 
most conveniently even dropped the namespace declaration on the root 
element, making it look easier than it is!). We have yet to see if the 
idea of having two namespaces for XForms is going to fly. At the moment, 
there is only one, and authors would therefore have to use prefixes (or 
default declarations) all over the place. That authors find this hard is a 
known fact (just ask Micah).

In addition, all the examples use at least one level of indirection -- and 
that's the simple examples. In my experience, indirection is something 
authors find verz difficult. Just look at the number of people who fail to 
understand how CSS works -- CSS! The concept of saying "this is a 
paragraph in a list item in a list" and then saying "paragraphs in lists 
are blue" in a different place in a file is something that many HTML 
authors struggle with ("but I just want it blue! Why can't I just say I 
want it blue?"). XForms, by virtue of requiring (even in "easy" mode) that 
the design be ultra-clean, requires just the same kind of abstraction.


EASY WEB FORMS

Here's the HTML forms equivalent of your first example (I added <p> 
elements to make the document have less dubious semantics):

   <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
     <title>Booking</title>
    </head>
    <body>
     <form action="http://www.example.org/update.asp">
      <p><label><input name="fn"> First name</label></p>
      <p><button>Save</button></p>
     </form>
    </body>
   </html>

Same result, no unnecessary abstraction. Accessibility of this document is 
fine, across all media and all devices, just like the XForms equivalent.


> The mark-up doesn't look that difficult to me!

I didn't say it looked difficult to you. I said it looked difficult to the 
average HTML author.


SAME DATA ... DIFFERENT SERVERS

Using the proposed WF2 features, your second example becomes the following 
HTML:

   <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
     <title>Booking</title>
    </head>
    <body>
     <form action="http://www.example.org/update.asp">
      <p><label><input name="fn"> First name</label></p>
      <p><button>Save</button></p>
      <p><button action="http://www.example.org/delete.asp"
                 name="delete">Delete</button></p>
     </form>
    </body>
   </html>

Note the name="delete" bit which can be used to make the above even 
continue working with existing UAs, if the server wants to handle it.

This is the key difference between your examples and my WF2 equivalents: 
Yours do not work in current UAs. My equivalents work everywhere today, 
and merely provide an improved experience in UAs that support WF2.


POST GETS MORE POWER

Supporting a new kind of submission format is no big deal -- Web Forms 2 
introduces an XML-based format, for instance. By adding this:

   <form ... method="post" enctype="application/x-www-form+xml">

...to any existing HTML form, you instantly make it submit XML in new UAs 
instead of the &-delimited format (and you can keep supporting the old UAs 
if you want by converting on the server side).


VALIDATION

Yup, WF2 introduces validation too, except that it doesn't require you to 
separate the data types from the controls (something that authors, IMHO, 
would find confusing).

Your example would become (with a few additional elements to introduce 
some HTML semantics to the thing while I'm at it):

   <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
     <title>Demo</title>
    </head>
    <body>
     <form action="http://www.example.org/update.asp">
      <p><label>First name: <input name="fn" type="text"></label></p>
      <p><label>Date: <input name="date" type="date"></label></p>
      <p><label>Beds: <input name="beds" type="number"></label></p>
      <p><label>Smoking: <input name="smoking" type="checkbox"></label></p>
      <p><button>Save</button></p>
     </form>
    </body>
   </html>

No need to give any alerts, by the way, the UA takes care of it in WF2.

The Web Forms processor will check the data entered against the data 
types, and give feedback on any errors.

The processor will also prevent the data from being submitted if it's 
invalid, and will generate an appropriate error message (so no need to 
hardcode the message in the source).

And the form will still work in existing UAs, with the additional checking 
enabled in WF2-capable UAs. (For legacy UAs, the server can provide the 
error checking -- it has to do so anyway to protect against hostile data.)

Note how the above uses no script (nor regular expressions).

This is what I mean when I say that it is quite possible for HTML to be 
extended to do the most important things of XForms without breaking 
backwards compatibility.


> In fact, as my examples show, XForms allows you to produce forms with a 
> lot of functionality, but without using any scripting, which means that 
> XForms actually *lowers* the bar, allowing those who do not know 
> scripting to produce more useful, device-independent, cross-platform 
> forms.

You characterise scripting as raising the bar, but in my experience 
authors simply use copy and paste, so it makes no difference (to those 
authors) whether a solution uses declarative angle brackets or imperative 
semicolons. And frankly, so long as the end result is semantic, it doesn't 
matter (the accessibility is the same both ways).

But I agree that removing scripting does make it neater, and that's why 
the Web Forms 2 proposals introduce declarative ways of doing the most 
common form things.


Again, none of this is supposed to be a criticism of XForms. As I've 
pointed out many times, I personally think XForms is a well-designed 
language, with many great features. However, it is not backwards 
compatible with existing content and user agents, which I fear is 
dramatically reducing the level of interest people have in it. I have 
already heard people (including representatives of large content 
producers) tell me they are confused as to why XForms is being pushed so 
hard since they are quite happy with their HTML documents and just want a 
few new features to make their lives easier.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 13 March 2005 17:22:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:00 GMT