Re: An heresy about labels for XForms 1.2

Hi Leigh and Kurt,

Absolutely, +110%.

Though particularly acute in XHTML, this is a pain in the neck for *any* 
XForms host language.  The form workarounds needed to ensure a11y while 
still offering precision control over the visual rendition are ugly and 
reduce performance.  The processor/language is the better place to make 
this connection.

>From a schema perspective, this would mean that at least xf:label would 
become a top-level element.  Although xf:label is part of a cluster of 
metadata elements that include hint, help and alert, I imagine you mean to 
do this only for label, right?

Cheers,
JB




From:
Kurt Cagle <kurt.cagle@gmail.com>
To:
Leigh L Klotz Jr <leigh.klotz@xerox.com>
Cc:
public-forms@w3.org
Date:
01/19/2011 05:02 PM
Subject:
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.