W3C home > Mailing lists > Public > www-forms@w3.org > December 2003

Re: Proposal for Extensions to HTML4

From: <andyh@collegenet.com>
Date: Mon, 8 Dec 2003 18:06:22 -0800
To: www-forms@w3.org
Message-ID: <OFF52B0381.4F8BC79C-ON88256DF6.007F7B48-88256DF7.000B838A@collegenet.com>

> due to its complexity and the way it
> separates content and data, something which most developers don't
> understand or want

> > The separation of presentation from content ...
> Completely agreed. My proposal addresses this (as does HTML4's forms).

Of course that is a matter of opinion. But lets look at an example of where
XForms is "complicated"...
Imagine that you have a HTML page with a set of radio buttons, but you
realize that the number of options has increased to a point where it is not
acceptable to use that UI element and a dropdown select box is more
appropriate. So your UI specialist hunts down a developer who trawls
through a bunch of perl code and starts changing <input type="radio"> into
<select> and <option> tags.
Meanwhile in our XForms implementation, our UI specialist opens a html page
and changes @appearance="full" to @appearance="minimal".

>> The concept of a null value is very important
> This is simply a matter of backwards compatibility with HTML4.

Which is an example of why HTML4 is broken. Null values just cannot be

> Help attribute

The implementation of the XForms help element (just like everything) is up
to the UA. A keyboard driven interface will use F1 as normal (and general
users do not distinguish between UA help and application help), whereas a
PDA would do something different.

> You don't submit a form to a Web service (how on earth would the UA know
> how to render the returning envelope?)

Because the data and UI are separated!
An example would be a zipcode resolver, where after a user has entered an
address a request is made to a service/resource that returns the correct
zipcode that is copied into the user's data. There is no need for the user
to do anything.
XForms submission is more than posting data back to a server, it also the
mechanism to gather additional data part way through a transaction.

> Hooking a
> little script into the submit event of a form that cancels the submission
> and then does it manually using the aformentioned interface allows this
> system to be used for all manner of REST-based Web services.

And therein lies the problem. Just because we can do it with "a little bit"
of script doesn't mean to say that we should continue doing it. Afterall
isn't everything just a little bit of machine code? It's almost 2004 and
application development should be getting easier and clearer. Machines can
write code.

Andy Heydon
Received on Monday, 8 December 2003 21:06:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:10 UTC