Re: An heresy about labels for XForms 1.2

Personally, I believe that this is long overdue, as labels in the current
structure have to be some of the most irritating aspects of XForms.

A couple of use cases to consider:

<table>
<xf:repeat>
     <tr>
           <td><xf:output ref="foo"><xf:label>Foo</xf:label></td>
           <td><xf:output ref="bar"><xf:label>Bar</xf:label></td>
           <td><xf:output ref="bat"><xf:label>Bat</xf:label></td>
     </tr>
</xf:repeat>
</table>

is not an usual situation for XForms usage (yes, I know it's technically
illegal because of the way that HTML is specified, but bear with me)

Without knowing apriori the substrate structure around this form fragment,
the label should end up repeating multiple times, once for each property.
This is probably not the desired goal. However, rendering this so that it
appears in a consistent manner with CALS tables elsewhere is one of the CSS
nightmares reserved for the truly damned.

To me, the logical mapping for this would be:

<table>
     <tr>
           <th><xf:label for="_foo">Foo</xf:label></th>
           <th><xf:label for="_bar">Bar</xf:label></th>
           <th><xf:label for="_bat">Bat</xf:label></th>
     </tr>
<xf:repeat nodeset="records/record">
     <tr>
           <td><xf:output ref="foo" id="_foo"/></td>
           <td><xf:output ref="bar" id="_bar"/></td>
           <td><xf:output ref="bat" id="_bat"/></td>
     </tr>
</xf:repeat>
</table>

Not only does this turn the labels into column headers, but it also makes it
far easier to render this kind of structure.

Similarly, if you have mediatype content, labels can be problematic. For
instance, consider:

<xf:output ref="myImageUrl" mediatype="img/*">
     <xf:label ref="../myImageUrlTitle"/>
</xf:output>

In the above case, it's often preferable to render the label either above or
below the picture, but the CSS to do this is actually pretty complex,
especially when dealing with floating content.

<div>
     <div><xf:output ref="myImageUrl" mediatype="img/*" id="image"/></div>
     <div><xf:label ref="myImageUrlTitle" for="image"/></div>
</div>

is far more self evident in its execution and works on the same context as
the output rather than having to ascend to the original context.

I think the biggest argument for @for would be in languages such as SVG,
where labels may very well be specified at a very different part of the
underlying rendering than the associated controls. The containment structure
can be worked around somewhat there, but having independent labels could
make development of these controls considerably less of a headache.

I'd recommend strongly that we incorporate @for into xf:label and possibly
into xf:message as well (modeless xf:messages in particular would be a very
good candidate, as these may as often as not appear either in tooltips, to
the right of or below the corresponding component, all of which have
rendering issues.

Kurt Cagle
XML Architect
*Lockheed / US National Archives ERA Project*



On Wed, Jan 19, 2011 at 5:58 PM, Leigh L Klotz Jr <leigh.klotz@xerox.com>wrote:

> For a number of years, I've struggled and watched others struggle using CSS
> to control XForms layout.
>
> By all rights, XForms and CSS should be easier to lay out than HTML4 forms,
> but even making allowances for the lack of CSS3 pseudo-property and
> pseudo-element support, and even after the Venice Accord proclaiming
> standard CSS class names for XForms elements and model item property states,
> it's remains a difficult task to control the layout of form controls and
> labels.
>
> XForms has a strong connection between a form control and its label, and
> for A11Y reasons not only requires labels, but captures the connection
> between them by hierarchy: a label is contained immediately within the
> control it labels.
>
> Unfortunately, this container-ship, and more importantly the document
> order, makes it much more difficult to lay out XForms labels on the page
> than it is to lay out HTML4 forms and their labels.
>
> HTML4 provides a nod to A11Y by giving label an attribute "for" which is
> the ID of the form control to which it corresponds.
>
> I'd like to suggest we experiment with this same mechanism: require form
> controls to have labels, but allow the label to be id-linked with label/@for
> instead of required by a schema expressing a required child element.  Of
> course, we'd need to specify the id-resolution rules in repeat as the same
> as setfocus/@control.  More importantly, we'd need to tell implementors that
> MIP properties such as readonly and required and relevant must apply to the
> label/@for a control just as if the label were contained lexically within
> the form control.
>
> In result, we would still retain the A11Y features of HTML4 forms, and make
> it easier to author XHTML+XForms for today's authors, while still allowing
> all existing XForms input/label structure.  XForms 1.0 processors would
> likely even process the label/@for mostly correctly, except for the
> propagation of MIP states.
>
> What do others think about my heresy?
>
> Leigh.
>
>
>