W3C home > Mailing lists > Public > public-appformats@w3.org > August 2006

Re: IBM Position Statement on XForms and Web Forms 2.0

From: Dave Raggett <dsr@w3.org>
Date: Thu, 31 Aug 2006 16:59:50 +0100 (BST)
To: Mark Birbeck <mark.birbeck@x-port.net>
Cc: public-appformats@w3.org, www-forms@w3.org
Message-ID: <Pine.LNX.4.64.0608311617030.6011@holly>

On Thu, 31 Aug 2006, Mark Birbeck wrote:

> The fallback idea is an interesting issue, and as I said, one
> that has for a long time been on our 'to do' list in the XForms 
> WG. It's pretty straightforward to do and deserves more 
> attention...but it's not such a big deal that the WHAT WG needed 
> to write a new spec for it. Adding this kind of thing to XForms' 
> MVC architecture is a breeze.

Implementing MVC with HTML forms is indeed quite easy and where 
XForms got started. In my work on HTML Tidy, I found that one 
pernicious problem with forms as defined in HTML4 is the need to 
enclose form fields in a form element. In many cases this is fine, 
but you also come across cases where websites have used tables for 
layout and found that they couldn't do so while maintaining the 
proper nesting of table cells and form elements. This gave HTML Tidy 
a case of serious indigestion in trying to figure out the closest 
markup that conformed to the HTML4 spec. If only we had gotten form 
fields to refer to their form by reference when we first started on 
HTML Forms back in the early nineties! Thankfully, today, CSS 
support has advanced to the point where you can dispense with tables 
for layout and hence steer clear of this particular problem.

Early work on HTML also proposed the use of attributes on form
fields for data constraints, but met with little enthusiasm at
the time from browser vendors. Of course, you can add them yourself 
and interpret them from a Web page script, but then you don't
get the benefits that come from lots of people using the same
standard. The use of clean markup and modular scripts makes for
reduced development and maintenance costs, but it is even better
if you can drop the need for some of the script libraries and the
problems that always seem to rear up with such libraries when new 
versions of browsers are released.

In the long run, Web developers are going to be more concerned over 
the cost of creating and maintaining Web applications, than in 
learning a new markup language. That's why languages like DIAL are 
so valuable - DIAL is a W3C markup language combining XHTML and 
XForms and aimed at authors rather than browser vendors. It is an 
example of the power of declarative techniques to reduce human 
effort, and is designed to be machine translated to suit the 
specific browser/platform that people have in front of them.

Incremental improvements to native support for HTML are likely to 
take a long time to take hold due to the sheer number of users and 
the different rates at which they upgrade their browsers. Changes to 
how people author Web applications have the potential to spread much 
faster, but both approaches can proceed in parallel and I look 
forward to seeing what can be achieved.

p.s. one indicator of progress would be the disappearence of
websites that demand users to type credit card numbers without
the intervening spaces that appear on the card, and which make
the numbers much easier to read. This is an example of a bad
meme, and can be addressed with a single line of script.

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)
Received on Thursday, 31 August 2006 16:00:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC