Re: [Fwd: Re: XForms: Question about tax form example]

Hi Erik,

One place where I think labels-separate-from-individual-controls makes 
sense is repeating sections.

Say a repeat has Quantity/Description/PartNumber/Price/Extension. It 
would be nice for a way to mark up the labels once, with the controls 
repeating underneath (instead of the labels repeating with each 
additional line item).

.micah

Erik Bruchez wrote:

>
> 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
>


-- 
  Available for consulting. XForms, web forms, information overload.
  Micah Dubinko                           mailto:micah@dubinko.info
  Brain Attic, L.L.C.                        http://brainattic.info
  Yahoo IM: mdubinko                                +1 623 298 5172
  Learn XForms today: http://xformsinstitute.com
  BPM in plain english: http://bpmfocus.com

Received on Thursday, 16 June 2005 15:17:47 UTC