Re: An heresy about labels for XForms 1.2

Kurt,

you could achieve complete control over the table structure with the
xf:repeat-* attributes:

<table>
  <thead>
    <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>
  </thead>
  <tbody 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>
  </tbody>
</table>

However, your mileage may vary regarding xf:repeat-* support in XForms
implementations.

Regards,
Uli.

On 20.01.11 01:58, Kurt Cagle wrote:
> 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
> <mailto: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.
> 
> 
> 


-- 
Ulrich Nicolas Lissé

Received on Thursday, 20 January 2011 19:41:16 UTC