- From: Erik Bruchez <erik@bruchez.org>
- Date: Thu, 16 Jun 2005 06:10:28 +0200
- To: www-forms@w3.org
Hi all, I was fairly firm in my belief that xforms:label must be within a control, but apparently some think otherwise, and implementations appear to allow randomly placed xforms:label elements. It seemed to me that the idea behind xforms:label was to be a label for a specific control, not just a generic mechanism to display a label, this based on the following text from the spec: "8.3.3 The label Element - This required element labels the *containing form control* with a descriptive label." Whatever the spec actually says, I don't really see the benefit of using xforms:label outside of a control. You can use xhtml:label instead, or just some other constructs from the host language. Then what about xhtml:hint, xhtml:help, and xhtml:alert? Can they also be used outside of controls? Can anybody shed some light on this question? See below the relevant message from netscape.public.mozilla.xml. -Erik -------- Original Message -------- Subject: Re: XForms: Question about tax form example Date: Mon, 06 Jun 2005 12:12:41 -0500 From: Aaron Reed <aaronr@us.ibm.com> Organization: Another Netscape Collabra Server User Newsgroups: netscape.public.mozilla.xml References: <d6sb66$ian6@ripley.netscape.com> <d72b5i$ci01@ripley.netscape.com> <d7pn1i$ka513@ripley.netscape.com> Erik Bruchez wrote: > Aaron Reed wrote: > >> We created this particular XForm to give an example of what a user's >> experience is with XForms. It is not, however, a good example of >> proper XForms authoring (as noted in the Disclaimer toward the top of >> the form source). Due to a variety of limitations that currently >> exists in our XForms implementation, we could not achieve the >> table-type of layout that we desired in any other way. When our next >> preview release comes out and we can achieve the desired layout in the >> 'proper' way, we'll update these samples and include new samples. > > > Thanks for the explanation. > >> As far as bugs, there is nothing that says that a label MUST be >> contained in a form control, though that is often the case and is >> pretty much what it was designed for. So the fact that a label will >> render outside of a form control is not a bug. > > > The spec says (8.3.3): > > "This required element labels the containing form control with a > descriptive label." > > That is also how the xforms:label element is used in the XForms spec > examples. See section 2.1 for example: > > "Form controls always have labels directly associated with them as child > elements—this is a key feature designed to enhance accessibility." > > See also section 8.1, "8.1 The XForms Form Controls Module". The label > element is part of the minimal content model for most of the elements > there. Section 9.1, "9.1 The XForms Group Module", shows that you can > have one optinal label within xforms:group elements. > > Based on this, the xforms:label element: > > 1. Has a containing form control > 2. Is required exactly once within most form controls > 3. Is sometimes optional (but with one occurrence at most), for example > within xforms:group > > So I stand by my initial claim that this is a bug, and that you cannot > use xforms:label the way the Tax form example does. I would definitely > appreciate a convincing argument (i.e. reference to the spec and/or > errata) saying otherwise. > > -Erik Hi Erik, I agree with 2 and 3. 1 should be 'may have a containing form control'. In none of the quotes you provided (nor anywhere in the spec) is label restricted to only being a child of certain form controls. The fact that formsPlayer, X-Smiles, and Novell's XForms processors all render labels outside of controls without error leads me to believe that we are behaving correctly. We are compatible with other implementations who have a similar interpretation of the spec. If the WG wanted labels only contained in form controls, then they could have enforced this in the XForms schema or turned the label into an attribute on a form control, but they didn't. Because it isn't restricted by the spec, then we should allow the form author maximum flexibility while maintaining compatibility with other implementations. We can't always predict how a form author may chose to use a control to meet their needs. More on this topic is addressed by this thread in the W3C's mailing list archive: http://lists.w3.org/Archives/Public/www-forms/2005Mar/0066.html Thanks for your comments, --Aaron
Received on Thursday, 16 June 2005 04:10:56 UTC