Re: An heresy about labels for XForms 1.2

Uli,

Yup. I was writing on my phone and couldn't remember the exact attribute
syntax. Thx.

Kurt
On Jan 20, 2011 2:40 PM, "Ulrich Nicolas Lissé" <unl@dreamlab.net> wrote:
> 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é