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

 
[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:mark.birbeck@webbackplane.com] 
Sent: Thursday, December 10, 2009 3:10 AM
To: Klotz, Leigh
Cc: www-html-editor@w3.org; public-forms@w3.org
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

mark.birbeck@webBackplane.com

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)

Received on Friday, 11 December 2009 16:38:55 UTC