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

RE: A forms-lite straw man

From: Marcos Caceres <m.caceres@qut.edu.au>
Date: Wed, 6 Sep 2006 15:23:49 +1000
To: "'Matthew Raymond'" <mattraymond@earthlink.net>, "'John Boyer'" <boyerj@ca.ibm.com>
Cc: <public-appformats@w3.org>
Message-ID: <004e01c6d174$a26753d0$e735fb70$@caceres@qut.edu.au>

To throw in my two cents on the labels inside/outside discussion, html
labels are also sometimes used in what seems to be counter intuitive ways,
but make a lot of sense from a UI design perspective. Consider the following
tag-soup example: 

		display: inline; text-decoration: underline; color: blue;

<p class="warningSign">
	Your <label for="lastName" class="fakeLinkLabel">last name</label>
is required, 
	but you did not provide it.

	<label for="lastName">Last name:</label> 
	<input type="text" id="lastName" value=""/>
	<input type="submit" id="submitButton"/> 

	Actually, we don't need your last name after all,  
	<label for="submitButton" class="fakeLinkLabel">submit the form

In the above example, the user is able to select the first label to give
focus to input 'lastName'. The second label element is how most people use
label, ie. to give meaning to the input box through a presentational (or
otherwise) proximity relationship. With the third label, the user is able to
submit the form. 

As we all know, in HTML it is totally valid to have a label away from its
related input (and related form). In fact, it sometimes makes a lot of sense
to keep them completely separate (as shown above). In terms of labels, it
seems that XFORMS makes somewhat undesirable assumptions about the
presentation and relationships of labels to inputs by placing them as
children of an input element. IMHO, having a label inside the input assumes
a semantic relationship that is presentational in nature. Despite both
elements being abstract, I would argue that the parent child relationship
imposed by the XFORMS on inputs and labels is not strictly presentation
free. From a DI perspective, labels should be considered for their active
role in the UI as well as for their ability to 'anchor' the
human-understandable semantics of an abstract input. 


-----Original Message-----
From: public-appformats-request@w3.org
[mailto:public-appformats-request@w3.org] On Behalf Of Matthew Raymond
Sent: Wednesday, 6 September 2006 11:23 AM
To: John Boyer
Cc: public-appformats@w3.org
Subject: Re: A forms-lite straw man

John Boyer wrote:
> Hi Dave,
> This is a good start.
> I was also thinking that inputs should allow optional use of 'name'
> attribute instead of ref *and* label. This would allow implicit 
> creation of a 'flat' data structure.

   There's no point of deliberately discarding the <label> element in
(X)HTML. If there's no <label> for the element, then you could use the
|name| attribute as an unofficial label for general processing, but it
shouldn't replace <label> in the sense that it's used in HTML right now.

   Also, <label> inside <input> should be avoided. Web authors may see that
<input> has a close tag and assume that the contents are actually the
control value, similar to <textarea>, so having the <label> inside is

> Then, I was thinking that an input could also use a value attribute 
> (content string, not XPath) to indicate initial value of the named 
> node in the implicit flat data model.
> The point is that this:
> <input name="Name" value="John"/>
> would do the same thing as an XForm today would do with
> <xf:model>
>    <xf:instance xmlns="">
>        <data>
>          <Name>John</Name>
>       </data>
>    </xf:instance>
> </xf:model>
> <xf:input ref="Name">
>    <xf:label>Name</xf:label>
> </xf:input>

   +1, although I'd like to state again that we still need HTML <label>
elements for fallback.

| <form [...]>
|   <label>Enter your name:
|     <input name="Name" value="John"/>
|   </label>
| </form>

   Hmm. Now that I think of it, UI labels are not the same as labels for
individuals units in a data model.

   I strongly advocate keeping form for backwards compatibility. It can be
safely ignored when its XForms equivalent is present.
Received on Wednesday, 6 September 2006 05:24:09 UTC

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