Question to XForms authors and implementors: Multiple help, hint, alert elements per form control?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Question to XForms authors and implementors: Multiple help, hint, alert elements per form control?

Klotz, Leigh
In XForms 1.1 [1] the inline content model and linked schemas allow a plurality of help, hint, and alert elements per form control.
For example, at the end of section [2]:

  Content Set Minimal Content Model
  UI Common (help|hint|alert|Action)*

The Recommendation text gives no indication what more than one would do.

I raised this issue today [3] in the Forms WG teleconference.

In the past, there was group discussion about the advisability of using multiple label elements distinguished by xml:lang attributes, and we decided to support only one label element.  One argument was that I18N best practice calls for external references.

As far as I can tell, we had no discussion about multiple help, hint, or alert elements, and I believe their allowance is a result of insufficient precision in the inline content model.

We have proposed that a future erratum for XForms 1.1 note in the prose that multiple such elements per form control is at best not interoperable, and further that the schema definitions for which it can be conveniently disallowed be changed to do so.

Are any implementors assigning special meaning to multiple help, hint, and alert elements?

Leigh.

[1] http://www.w3.org/TR/2009/REC-xforms-20091020/
[2] http://www.w3.org/TR/2009/REC-xforms-20091020/#N74868
[3] http://lists.w3.org/Archives/Public/public-forms/2009Dec/att-0021/2009-12-09-v2.html#topic5
Reply | Threaded
Open this post in threaded view
|

RE: Question to XForms authors and implementors: Multiple help, hint, alert elements per form control?

Klotz, Leigh
 
[Moving this back to www-forms-editor as I mistakenly sent it to www-html-editor.]

Mark,

I see a larger issue here about the tension between implementor extensibility and authoring tools: a good schema for authoring would allow only that which is interoperable and recommended, while a good schema for implementors would require only minimal conformance and leave open the gates to innovation.  It may be that we need two schemas, with one closer to minimal for implementors and one closer to strict and interoperable for authoring.  (Implementations which provide extensions would be free to provide their own schemas with their own extensions, of course.)

You make a strong case for making an editorial change to XForms 1.1 to state that the first help/hint/alert is used, to clarify the existing text yet still allow room for expansion.  Allowing multiples of label would a normative change, since the XForms 1.1 Recommendation does not allow multiple labels.

Leigh.

-----Original Message-----
From: Mark Birbeck [mailto:[hidden email]]
Sent: Thursday, December 10, 2009 3:10 AM
To: Klotz, Leigh
Cc: [hidden email]; [hidden email]
Subject: Re: Question to XForms authors and implementors: Multiple help, hint, alert elements per form control?

Hi Leigh,

> We have proposed that a future erratum for XForms 1.1 note in the
> prose that multiple such elements per form control is at best not
> interoperable, and further that the schema definitions for which it
> can be conveniently disallowed be changed to do so.

Can I suggest that we don't be too restrictive? I would think that all we need to do is to work out what it takes to make things interoperable, were people to have multiple elements.

For example, we could simply say that authors can count on the first occurrence of one of these elements being processed, but after that, it will be application specific.

But doing this, we don't rule out any innovations that people might come up with.


> Are any implementors assigning special meaning to multiple help, hint, and alert elements?

We don't give it special meaning, but we don't disallow multiple elements, either.

When processors allow multiple elements to appear, then it creates some interesting possibilities. For example, CSS can be used to determine which of the elements gets displayed.

One illustration of this would be to have different labels and alerts depending on whether you are using a mobile or desktop device:

  @media screen {
    .handheld { display: none; }
  }
  @media handheld {
    .screen { display: none; }
  }

  <xf:intput ref="name">
    <xf:label class="handheld">Age</xf:label>
    <xf:label class="screen">Age at next birthday</xf:label>

    <xf:alert class="handheld">Age is required</xf:alert>
    <xf:alert class="screen"
      >You must enter your age. Come on...don't be shy.</xf:alert>
  </xf:input>

You could also have the label determined by the state of the control:

  .valid .reenter { display: none; }
  .invalid .enter { display: none; }

  <xf:intput ref="name">
    <xf:label class="enter">Age at next birthday</xf:label>
    <xf:label class="reenter">Please re-enter your age</xf:label>
  </xf:input>

Slightly contrived examples, I realise. :)

But I'm simply trying to illustrate that there are areas to explore, and I don't think we gain anything by closing off this avenue of exploration by tightening up the schema.

Regards,

Mark

--
Mark Birbeck, webBackplane

[hidden email]

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, London, EC2A 4RR)