Re: An heresy about labels for XForms 1.2

+1E3 for adding "@for" to the whole LHHA combo.

Regards,
Uli.

On 20.01.11 04:36, Erik Bruchez wrote:
> 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
> <mailto: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 <mailto:kurt.cagle@gmail.com>>
>     To:  
>     Leigh L Klotz Jr <leigh.klotz@xerox.com <mailto:leigh.klotz@xerox.com>>
>     Cc:  public-forms@w3.org <mailto: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_ <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:36:28 UTC