W3C home > Mailing lists > Public > public-forms-tf@w3.org > April 2008

Developing Design Principles for streamlined web forms

From: John Boyer <boyerj@ca.ibm.com>
Date: Wed, 2 Apr 2008 14:43:56 -0700
To: Forms WG <public-forms@w3.org>, public-forms-request@w3.org, public-forms-tf@w3.org
Message-ID: <OFBD0B2E97.944E9650-ON8825741F.00742E50-8825741F.007765FF@ca.ibm.com>
If you look closely at the email link for the XForms simplified syntax 
"strawman" view, you will see a number of the design principles shining 
through.  It would help to know if any of these are objectionable or 
acceptable from the HTML WG vantage point being provided by the TF members 
from the HTML WG.


For example, the 'name' attribute is used in combination with UI hierarchy 
to imply a data structure hierarchy that is then addressable in 
calculation formulae for both values and properties like relevant and 

In XForms, we can use this with a "select1" control, and we think that web 
authors should have the *option* of using a select1 control if they do not 
care as much about graceful degradation on down level UAs.

However, this is an *option* for authors, and I would except that the HTML 
WG would still choose to "fit" the existing select control into the same 
set of principles for what the name attribute is being defined to imply.

So let's start with the concepts around the name attribute.

We can also push on the "Degrade Gracefully" principle with respect to how 
"repeat" tables operate.  The proposal includes using the *same* name 
attribute on our repeat element as the way to dynamically do tables.  This 
seems to be about the same level of graceful degradation as any other 
proposal for dynamically repeating UI content, so it's unclear why 
adopting something other than the constructs already developed to W3C 
Recommendation through the Forms WG makes any sense.

John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 

Maciej Stachowiak <mjs@apple.com> 
Sent by: public-forms-request@w3.org
04/02/2008 01:54 PM

"Gregory J. Rosmaita" <oedipus@hicom.net>
John Boyer/CanWest/IBM@IBMCA, public-forms-tf@w3.org, Forms WG 
<public-forms@w3.org> (new)
Re: XForms Simplified Forms Syntax Review Needed

On Apr 2, 2008, at 1:29 PM, Gregory J. Rosmaita wrote:

> aloha, fellow forms task force members!
> maciej wrote, quote:
>> (Fellow Forms TF members, I think it's time we come up with a
>> draft of  the guidelines so we can satisfy our obligations to
>> the Forms WG and  HTML WG.)
> unquote
> i believe that it is high time that the Forms and HTML working groups
> reconsidered the joint forms task force and its goals, with an eye
> towards dissolving the old task force and its charter, and drafting a
> new one; we have been going nowhere at no particular speed, and it is
> in everyone's best interest to consider not merely "guidelines" but
> specific proposals -- as long as the HTML5 draft has a ToDo where the
> "Forms" section should be, there will be very little progress on this
> front, unless we re-examine the joint task force's purview...

I am in favor of dissolving the Forms Task Force, since so far we have 
produced anything of value. However, I have felt reluctant to propose 
this, since I have been part of the problem (have not really done 
anything myself).

I would be against chartering a Task Force to create a new set of 
elements and associated semantics to add to HTML. That is the job of 
the HTML WG. I would also be against chartering a Task Force to create 
a new syntax for XForms. That is the job of the Forms WG.

 From my superficial perusal of John's proposal, it does not appear to 
me that it would satisfy the HTML WG's Design Principles as written. 
Perhaps it will be improved such that it does. It also seems pretty 
incomplete, for example, what exactly is the language used in the 
"calculate" attribute,  But I would be against using a Task Force to 
bypass review by and input from the full HTML Working Group.

> if that is not acceptable to my fellow joint task force members, then
> i suggest that the joint task force as currently constituted be
> dissolved by mutual consent of the chairs of both working groups, and
> that it be replaced with a task force that will produce more tangible
> deliverables...  when i am asked about the gaping hole in the HTML5
> draft where forms should be addressed, i'm not being queried as to
> what theoretically might one day appear there, but specifically what
> WILL appear there...

The primary proposal on the table is Web Forms 2.0, an extension to 
HTML4 Forms that appears to satisfy the design principles. Currently 
its integration is blocked by waiting on the Forms TF to complete its 
work. I do not think creating a new TF with a broader scope would 
reduce this delay.

> i proposed at our first (and so far only) telecon that we examine
> dave raggett's XForms Transitional, but that suggestion went over
> like the proverbial lead ballon...  we must, as a task force and
> as members of our respective groups, reconsider our approach to
> forms in HTML5 and XHTML and either be chartered/tasked with providing
> concrete proposals, or we should remove HTML5 from TR space as a
> working draft, for how can one write a specification for the web that
> does not address forms, given the fact that i am using one to compose
> this, use them every day to post to wikis, and to conduct ecommerce?

I think the right thing to do is to integrate Web Forms 2 integrate 
the HTML5 spec immediately. If a better proposal comes along then it 
should be entertained.  But we have a complete and detailed proposal 
in hand, which the HTML WG has already voted to adopt. Right now it is 
waiting on the Forms TF. I would like to complete the HTML WG's 
resolution to adopt Web Forms 2 and take any proposals for changes 
under review in the normal way.

Let us remove the Forms TF as a blocker to progress.

Received on Wednesday, 2 April 2008 21:44:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:06 UTC