Re: An heresy about labels for XForms 1.2

Leigh: it's not a heresy: it's absolutely needed, and it's been implemented
in Orbeon for a long time already.

Kurt: good point about repeats.

John: we happen to implement @for on hint, help, and alert too (the whole
"LHHA" combo). With HTML as host language it makes a lot of sense: we
produce HTML markup for all the LHHA elements and the layout issues can the
same. Sure an alert might be translated as an overlay or alert, but it may
as also not be (and in which case the markup can be hidden with CSS, and
e.g. JavaScript in charge of displaying the alert).

This allows you to do things like:

<td><xf:label for="foo">Name</xf:label></td>
<td><xf:input id="foo"></td>
<td><xf:alert for="foo">Incorrect value</xf:alert></td>

-Erik

On Wed, Jan 19, 2011 at 5:27 PM, John Boyer <boyerj@ca.ibm.com> wrote:

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