[whatwg] forms-lite testbed

[Matthew Raymond]

   Note, before you go on, that I do appreciate that you're trying to
make extensions to Web Forms that are less dependent on scripting than
something like Web Forms 2.0. However, in many cases, the scripts web
authors would have to write when using WF2 are not significantly
different from the formulas you replace them with, nor are they
significantly more difficult to understand for web authors well versed
in Javascript. Considering you're actually implementing your testbed
using Javascript, the anti-scripting, pro-formula slant makes even less
sense.

Dave Raggett wrote:
> Here is a summary of the new attributes and what they do:
> 
>   calculate
[Snip!]

   The example you give in support of this attribute is something like this:

| <form name="form1" onsubmit="false">
|   <p>
|     <input name="x" datatype="number"> +
|     <input name="y" datatype="number"> =
|     <input name="sum" calculate="x+y" datatype="number"
|            readonly="readonly" value="0">
|   </p>
| </form>

   The same thing can be accomplished in WF2 using <output> and
|onforminput|:

| <form>
|   <p>
|     <input name="x" type="number"> +
|     <input name="y" type="number"> =
|     <output name="sum" onforminput="value = x.value + y.value">
|       0
|     </output>
|   </p>
| </form>

   In fact, the WF2 approach is superior for two reasons. First, using
|onforminput| allows you to call a function rather than specifying the
entire formula in one attribute. Second, the "sum" would not be
submitted to the server because <output> is never successful for form
submission. This may seem like a weakness in WF2 until you realize that
the only way for the server to validate "sum" is to calculate the sum
all over again and compare the two values, which is pointless. Thus,
with <output>, no one is tempted to neglect server-side validation.

>   pattern
>     This is used with the input element to constrain input to
>     match a regular expression.

   How is this different from WF2?

http://whatwg.org/specs/web-forms/current-work/#the-pattern

>   additional values for the input type (or datatype) attribute
>     In particular, number and date. For dates, the value entered
>     by the user is converted into a standard form, e.g. 11 oct 2006
>     becomes "Wed, 11 Oct 2006". In principle the date type could
>     be used with a browser provided date picker.

   This is identical to what WF2 has:

http://whatwg.org/specs/web-forms/current-work/#date
http://whatwg.org/specs/web-forms/current-work/#number

   In addition, WF2 has several other new types that are also quite useful.

>   min and max attributes
>     These are both used on the input element in conjunction with
>     the number or date types, and constrain the value to be
>     between the min and max values supplied with these attributes.

   This is identical to WF2.

>   range and step
>     When the type attribute on the input element is set to
>     "range", the user interface changes to allow the user to
>     select a value between min and max, at increments defined
>     by the step attribute.

   Again, this is identical to WF2.

>   validate
>     The validate attribute is used with the input element to
>     supply an expression over form fields that evaluates to
>     true or false, e.g. <input name="y" type="number"
>     validate="y > x"/> which says that this field value
>     must be greater than the value of the field named "x".

   How is this better than simply using the |onchange| attribute in HTML4?

| <input name="y" type="number" onchange=
| "if (!(value > x.value)) {setCustomValidity("foo");return false;}">

   It is considerably shorter, but it doesn't allow you to set a string
indicating the reason the value didn't validate.

>   required (or needed)
>     This is an expression like validate but requires the user
>     to have filled out a value for the field. The library
>     evaluates expressions by first rewriting them and then
>     calling the JavaScript eval function.

   I don't see why required fields should have dependencies on other
fields. A simple |required="required"| attribute should suffice. If
you're submitting X and Y, why should Y define that X is required for
submission? Would the submission be successful if the user left both X
and Y blank? There might be a use case here, but you have yet to present
it. The WF2 version of |required| is all most web authors really need,
and if you do need more than that, you still have the HTML 4.1
|onsubmit| attribute.

>   relevant
[Snip!]

   While it would be nice to turn sections of the form on and off based
on certain input values, this can be accomplished via |onforminput| or
|onformchange|. It seems that many of your attributes are designed to
avoid the use of Javascript, only to replace it with script-like
formulas that would depend on Javascript for fallback.

   I would, however, be open to ideas on how to establish simple
dependencies without scripting. Perhaps something that uses |id| and/or
|name| values rather than formulas:

| <input name="sauce" type="checkbox">
| [...]
| <input name="stype" type="radio" needs="sauce" value="BBQ">
| <input name="stype" type="radio" needs="sauce" value="SweetSour">
| <input name="stype" type="radio" needs="sauce" value="HoneyMustard">
| <input name="stype" type="radio" needs="sauce" value="Ranch">

   The idea is that |needs| would declare the name of a control that
must evaluate to TRUE in order for the current control to be enabled.
For non-binary value controls, simply having a value would be sufficient.

   Then again, if you can live with scripting being a requirement, you
could just do this:

| <input name="stype" type="radio" value="BBQ"
| onforminput="enabled=!sauce.checked">

>   repeat
>     This attribute is used on the fieldset element when the
>     associated controls form part of a repeating group, e.g.
>     as in a sequence of line items in a purchase order.

   I don't see how this any more powerful than the WF2 repetition model.

> It so happens that Opera 9 has implemented WebForms 2.0 in such a 
> way that causes problems for using the required and type attributes. 
> My work around is to also support the use of "datatype" as a synonym 
> for "type", and "needed" for "required".

   "Required" doesn't make grammatical sense anyways. "Requires" or
"needs" would be better. As for |type|, you could have just used
alternative value names like "lite_number" or "lite_date".

> In closing, note that this is experimental work and hasn't been 
> subject to the rigorous testing needed for commercial products.
> My aim is to continue to improve the library as I become aware of 
> problems. If you are interested in helping with testing and further 
> development please let me know.

   Your time would be better spent on this project:

http://sourceforge.net/projects/wf2