W3C home > Mailing lists > Public > public-forms@w3.org > September 2007

The difference between input and textarea

From: John Boyer <boyerj@ca.ibm.com>
Date: Tue, 4 Sep 2007 22:49:02 -0700
To: Forms WG (new) <public-forms@w3.org>
Message-ID: <OF207AD8D7.0407B450-ON8825734C.007FA50E-8825734D.001FF8F2@ca.ibm.com>
Both input and textarea came from somewhere. They are based on the html 
controls of the same name.
Furthermore, textarea calls out the fact that it is intended for multiline 
text.  It seemed to me like a clarification to point out that input is 
therefore not intended for multiline text.

The working group's resolution to remove the wording in input is not, in 
my opinion, fully thought out.  Here is why:

1) The point of the XForms UI controls is to provide an "intent-based" 
user interface.  There is no point in having both input and textarea if 
there are *no* differences between them.  The different between input and 
textarea should be like the difference between select1 and select.  The 
select and select1 controls both exist because one intends to allow 
multiple user selections and the other does not.  What other difference is 
there really?  Same for textarea and input; one allows multiple lines of 
text input... and the other does not.

2) The argument that multiline has no meaning in the voice world does not 
hold water.  I am sure that sight-impaired people want to create text with 
multiple paragraphs just as much as the rest of us do.

3) How do we then answer the simple "search page" use case, which I 
thought we answered in part with XForms input.  I rather thought that if 
you hit Enter in an input, then the control implementation would commit 
its value to the form and then dispatch a DOMActivate to the input 
control.  The form author should then be able to put a DOMActivate handler 
in the input and run a submission.  It is a little less clear how one 
might implement a "default submission" based on bubbling of DOMActivate, 
but one problem at a time :-) here.  Saying that input can take multiline 
text means we have *no* ability to implement even the simplest search 
page.  I am sure it was the intention to cover this case, but I think 
assumptions were made that it would just work without specification due to 
"common knowledge" about how HTML's input works.

John M. Boyer, Ph.D.
STSM: 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
Received on Wednesday, 5 September 2007 05:49:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:45 UTC