W3C home > Mailing lists > Public > public-appformats@w3.org > September 2006

Re: A forms-lite straw man

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Thu, 07 Sep 2006 12:52:05 -0400
Message-ID: <45004E35.4020100@earthlink.net>
To: John Boyer <boyerj@ca.ibm.com>
CC: public-appformats@w3.org

John Boyer wrote:
> I'm pretty sure I didn't say or even imply that we were interested in
> discarding the label element.

   At the time, I didn't feel it was clear from your email, which is why
I responded.

> My prior post was not meant to be complete, spec-ready text but rather a
> single, isolated example.

   I appreciate your willingness to give examples. One can only argue
the theoretical for so long before putting forward something concrete,
but it takes a certain amount of bravery to put your ideas forward like

> If you have a label with a for attribute, whether or not it contains the
> control that it is "for", clearly that should be used as the implied
> value of the xforms:label, but if you don't have the label, then the
> content of name would be used.

   There was no |for| attribute because it was unnecessary in the
specific example I was giving. I was using implicit association. I'm a
big fan of |for| where it's appropriate. The <label> needs a closing tag
anyways, so implicit association is more economical and makes the
association more structurally obvious in markup.

   That said, it's not essential, but it is something that would have to
be supported for backwards compatibility with HTML.

> XForms is accessibility-friendly so each control *must* have a label,
> which means that when one isn't provided by the HTML markup, we would
> still have to define something as the label in order to map into the
> XForms conceptual model.  Technically, we could just map empty string,
> but the content of the name attribute is better than nothing.

   Agreed. Using |name| is better when there's no label.

> The overall point, though, is that we should be able to make a
> reasonably complete and flexible mapping from HTML into XForms land to
> minimize required document changes needed to access new features.  If
> the following appears:
>   <label for="f1">Given name</label>
>  <input id="f1" name="given" type="text"/><br />
> Then, we would define the processing for that to be "equivalent to" what
> we have already specified for:
> <xf:model>
>   <xf:instance xmlns="">
>       <data>
>          <given></given>
>       </data>
>   </xf:instance>
> </xf:model>
> <xf:input ref="given">
>    <xf:label>Given name</xf:label>
> </xf:input>
> The above would make it easier for authors to write the smaller
> documents and to port existing documents to XForms, and the clearly
> defined mapping would make it easier to create conversion tools that
> would allow the less sophisticated author to write what he knows, then
> convert to an explicit, and come to understand the new syntax, which he
> could then extend via advanced features of XForms that are more
> difficult express as attributes of the UI controls.

   While I agree that the two above should be equivalent, I'm not sure I
agree that there should be a conversion involved on the client side. If
you're going to do a client-side conversion, you might as well implement
WF2 using a XBL2 binding to XForms markup. (Actually, that's an
interesting idea, though it would be much easier to implement the
reverse on most browsers.)

> The bottom line is that people talk about separation of data and
> presentation, but less sophisticated users need a little help getting
> that separation to occur, and we have an opportunity to not only to help
> them do that but also to define new style HTML in a way that allows that
> separation to exist conceptually even when it isn't expressed in the
> document serialization.

   Implying information doesn't necessarily lend itself to conversion.
In fact, if the explicit form has no real benefit, conversion to a more
explicit for is pointless. I'm not saying that's the case here, I'm just
saying implicitness isn't a sufficient argument for conversion rather
than direct support.
Received on Thursday, 7 September 2006 16:52:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC