- 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>
Hi, 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: <style> .fakeLinkLabel{ display: inline; text-decoration: underline; color: blue; } .warningSign{...} </style> <p class="warningSign"> Your <label for="lastName" class="fakeLinkLabel">last name</label> is required, but you did not provide it. </p> <form...> <label for="lastName">Last name:</label> <input type="text" id="lastName" value=""/> <input type="submit" id="submitButton"/> </form> <p> Actually, we don't need your last name after all, <label for="submitButton" class="fakeLinkLabel">submit the form now!</label> </p> 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. Marcos -----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 counterintuitive. > 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