Re: The <label> issue

> A problem with this is the loss of context that the label is nested in.

Often, probably in most cases, a label resource, if not inline, is obtained
from another instance or model, e.g.:

  <label model="resources ref="my-label"/>

or:

  <label ref="instance('resources')/my-label"/>

or with variables:

  <label ref="$resources/my-label"/>

rather than being relative to the data associated with the control.

Granted there are cases where the label will be stored alongside the data.
In such cases, moving labels will be harder, but maybe that's still
acceptable.

The thing is that the label/@for proposal has lot going for it:

* it is compatible with how things are done in HTML
* it covers existing use cases
* it is implemented
* its syntax is fairly light

-Erik

On Wed, Feb 23, 2011 at 10:28 AM, Kurt Cagle <kurt.cagle@gmail.com> wrote:

> Steven,
>
> Sorry to have missed the meeting earlier - once again involved in the job
> hunt shuffle.
>
> Re: re-ordering labels for XForms. Take a look at the flexible box model:
> http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/. Chrome, Safari and
> Mozilla support it in their most recent releases, IE9 and Opera don't yet.
> Frustrating that we don't have universal support, but it's at least one
> place that the XForms group should keep an eye on, as it has obvious
> ramifications.
>
> Kurt
>
>
>
> On Wed, Feb 23, 2011 at 11:07 AM, Steven Pemberton <
> Steven.Pemberton@cwi.nl> wrote:
>
>> One of the problems we have with label is that CSS doesn't support us the
>> way we could hope it should.
>>
>> XSLT allows you to move content around to other parts of the document, but
>> unfortunately CSS doesn't. When we started with XForms, we had hoped that
>> CSS would mature to a more general styling language, but it hasn't (yet).
>>
>> The clearest case of wanting to move labels, is to the top of a <repeat>,
>> though there are some other lesser-occurring use-cases too.
>>
>> It is obvious that a work-round that is currently used is to have empty
>> labels, and use headings instead, which has clear semantic (and
>> accesibility) issues.
>>
>> Another option (that HTML used) would be to allow labels anywhere, and
>> then indicate which control they are for with @for.
>>
>> A problem with this is the loss of context that the label is nested in. I
>> have labels like this:
>>
>>         <label ref="@name"/>
>>
>> just to give a simple example. Such labels would not be movable without a
>> lot of extra work (especially when the label is in a repeat).
>>
>> That is why I have a preference for a construct that would move the label
>> content to another place, in the way that I would prefer CSS to do.
>> Strawman:
>>
>>        <labeltext from="@label"/>
>>        ...
>>        <input...>
>>                <label id="mylabel" ref="@foo"/>
>>
>> Steven
>>
>>
>