An heresy about labels for XForms 1.2

+1 from me on this  --- DSR and I added the id/for hack in 1995
to HTML4 --- in hind-sight it's a more flexible mechanism than
tightly bound lexical approach we took in XForms.

Leigh L Klotz Jr writes:
 > 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.
 > 

--

Received on Wednesday, 9 February 2011 22:13:52 UTC