Re: Comparison of XForms-Tiny and WF2

Dave Raggett wrote:
> Dean Jackson suggested I write up a brief comparison of XForms-Tiny 
> and WebForms 2.0. You can find this on the Forms wiki at:
> 
>        http://www.w3.org/MarkUp/Forms/wiki/XForms-Tiny
> 
> WF2 and XForms-Tiny both involve incremental extensions to HTML 
> forms as defined in HTML4 and DOM2 HTML. XForms-Tiny includes a much 
> richer range of features[...]

   Are you referring to HTML Web Forms or WF2?

> [...] that greatly reduce the need for page 
> specific scripting compared with WF2.

   I disagree. The scripting in WF2 that would be needed to support the
same features as XForms-Tiny (XFT) isn't significant. The benefits of
XFT are mostly ease-of-use and the fact that native support won't
require Javascript to be enabled. More on this later.

> This will effect the relative 
> cost of developing form-based applications with the two proposals 
> since Web page scripts are prone to bugs and these are expensive to 
> iron out.

   This is misleading. In most cases, the same functionality in WF2 can
be replicated by a single line of scripting.

> XForms-Tiny is also much easier when it comes to repeated 
> groups of controls, avoiding WF2's tight coupling to HTML tables. 

   There is no such tight coupling with tables. You're using
non-normative examples as the basis for this conclusion. In reality, the
WF2 repetition model is far more flexible and has a greater range of
features. I would point out that your own repetition model appears to
only support repetition in <fieldset> elements.

> This is important for device independent markup and the experience 
> offered to users on mobile devices.

   Note that <fieldset> repetition is possible with WF2, so your
argument here isn't valid. Besides, WF2 was implemented on Opera, and
they're a major distributor of web browsers for small devices.

> WF2's output element also raises challenges for 
> implementation on existing browsers.

   The <output> element is inline, and its contents are strictly for
fallback. Browsers that don't support it will just render the fallback.
Aside from a few CSS issues with obvious workarounds, this isn't an issue.

> The rich declarative features of XForms-Tiny lend themselves to 
> exporting the XForms model and constraints for use in server-side 
> data validation. In principle, XForms-Tiny could also be used to 
> submit structured form data as XML, although this has not been 
> implemented as yet.

   How would this compare to the multiple encoding methods available in
WF2? Specifically, application/x-www-form+xml.

   http://whatwg.org/specs/web-forms/current-work/#form-submission

> I strongly recommend you try out the examples on the XForms-Tiny testbed:
> 
>     http://www.w3.org/2006/11/XForms-Tiny/
> 
> The WebForms 2.0 submission can be found at:
> 
>     http://www.w3.org/TR/web-forms-2/

   Let's do a comparison using the XFT Testbed.

http://www.w3.org/2006/11/XForms-Tiny/

=== Data types, e.g. number and date ====

   WF2 has the types "number" and "date".

=== Constraining field values with regular expressions ===

   WF2 supports patterns via the |pattern| attribute.

=== Calculated fields using spreadsheet-like formulas ===

   Here is the element that calculates a value in the testbed example:

| <input id="f3" name="sum" calculate="x+y" datatype="number"
| readonly="readonly"/>

   This is the equivalent in WF2:

| <output id="f3" name="sum"
| onforminput="value = (+x.value) + (+y.value)">0</output>

   The <output> element has several advantages:

1) The control is never successful for form submission. Since all data
sent to the server needs to be validated for security purposes, you'd
have to redo the calculation server-side anyway, so submitting
calculations like these only serves to encourage web authors not to
validate the calculated value on the server. By contrast, <input
readonly> can be successful as defined in HTML 4.01.

2) Using <input> elements for elements that should never receive user
input directly or submit content is an abuse of the semantics of
<input>. By contrast, the semantics of <output> are specially tailored
for the purpose of calculated values.

3) On some web browsers, native widgets are used for <input> elements.
As a result, CSS may not be able to fully style <input> elements. On the
other hand, web browsers can style <output> in a manner similar to a <span>.

=== Min and max values ===

   These attributes are supported in WF2.

=== Range controls ===

   WF2 supports the "range" type and the |step| attribute.

=== Validation expressions ===

XFT:
| <input id="f2" name="y" datatype="number" constraint="y &gt; x"/>

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

=== Required fields ===

XFT:
| <input id="f2" name="y" type="text" needed="x != ''"/>

WF2:
| <input id="f2" name="y" type="text"
| onformchange="required=(x.value != '')" >

=== Relevant groups of fields ===

XFT:
| <input id="f2" name="y" datatype="number" relevant="x &lt; 4"/>

WF2:
| <input id="f2" name="y" datatype="number"
| onformchange="disabled=!(+x.value &lt; 4)">

=== Repeating fieldsets ===

XFT:
| <fieldset name="lineItem" repeat-number="4">
| <legend>Repeating groups of fields</legend>
| <label for="item">Product Name</label>
| <label for="quantity">Number Purchased</label>
| <label for="unitprice">Price Per Unit</label>
| <input name="item" datatype="text" title="product name"/>
| <input name="quantity" datatype="number" title="number purchased"/>
| <input name="unitprice" datatype="number" title="price per unit"/>
| </fieldset>

   Note in the above, you have labels associated with multiple controls,
which isn't possible in HTML 4.01. Also, one would expect the labels to
pass focus if activated, but which <input> in the column would it pass
focus to?

   WF2 can duplicate this example with the added benefit of having a
label for each control:

| <fieldset>
|   <legend>Repeating groups of fields</legend>
|   <p id="order" repeat="template" repeat-start="4">
|     <label>
|       Product Name
|       <input name="row[order].item" type="text">
|     </label>
|     <label for="quantity">
|       Number Purchased
|       <input name="row[order].quantity" type="number">
|     </label>
|     <label for="unitprice">
|       Price Per Unit
|       <input name="row[order].unitprice" type="number">
|     </label>
|   </p>
| </fieldset>

   Alternatively, you could consider this input tabular, so you could
use a table with column headers:

| <table>
|   <thead>
|     <tr>
|       <th>Product Name</th>
|       <th>Number Purchased</th>
|       <th>Price Per Unit</th>
|     </tr>
|   </thead>
|   <tbody>
|     <tr id="order" repeat="template" repeat-start="4">
|       <td><input type="text" name="row[order].item"></td>
|       <td><input type="number" name="row[order].quantity"></td>
|       <td><input type="number" name="row[order].unitprice"></td>
|     </tr>
|   </tbody>
| </table>

=== Initializing fieldsets ===

   Web Forms 2.0 not only supports adding, deleting and moving rows, but
also supports initialization of both specific rows and rows that are
generated on the client by the repetition model.

   By contrast, XForms-Lite only supports initialization of the
beginning rows, and doesn't yet support the addition, deletion and
moving of rows at all. It may be a simpler repetition model, but only
because it lacks power and flexibility.

=== Using radio buttons to determine relevancy ===

XFT:
| <input id="maiden" name="maiden"
| relevant="gender=='female' &amp;&amp; married"/>

WF2:
| <input id="maiden" name="maiden"
| onformchange="disabled=form1.namedItem('female')!='female' ||
| married.value!='married')"/>

   The WF2 version is definitely not ideal, though it may be an issue of
my limited knowledge of Javascript...

=== Calculations involving selection fields ===

   This particular example just seems to be a retread of previous examples.

=== Calculations involving checkboxes ===

XFT:
| <input name="total" readonly="readonly"
| calculate="crustPrice(size)+toppingPrice(size)*count(toppings)"/>

   This is actually more difficult to do with scripting. Guess I'll have
to use the Selectors API...

WF2:
| <input name="total" readonly onformchange=
| "var size=+(document.matchSingle('input[name=size]:selected').value);
| var toppings=
| document.matchAll('.toppings input[type=checkbox]:selected').length;
| value=crustPrice(size)+toppingPrice(size)*count(toppings)">

   Not as compact, but it's manageable.

=== Referring to fields within named fieldsets ===

   I don't really understand the point of this example. The fallback is
suboptimal because values for the |name| attribute are reused in the
same form. Furthermore, the user knows where the package is going
because they just filled out the address. Also, you could have just had
"fieldsetname.city" in the |name| attributes, which would have preserved
fallback while at the same time allowing you to use the same value for
|calculate|.

=== Editable selection lists (combo boxes) ===

XFT:
| <select name="fruit" id="f1" editable="12">
|   <option>apples</option>
|   <option>pears</option>
|   <option>bananas</option>
|   <option>pineapple</option>
| </select>

WF2:
| <input name="fruit" id="f1" type="text" value="12" list="f2">
| <datalist id="f2">
|   Or select from the list:
|   <select name="fruit">
|     <option>apples</option>
|     <option>pears</option>
|     <option>bananas</option>
|     <option>pineapple</option>
|   </select>
| </datalist>

   Note above that <datalist> allows the markup to degrade in such a way
that you still have the choice of using text input or a list. However,
the fallback is optional:

| <input name="fruit" id="f1" type="text" value="12" list="f2">
| <datalist id="f2">
|   <option label="apples"></option>
|   <option label="pears"></option>
|   <option label="bananas"></option>
|   <option label="pineapple"></option>
| </datalist>

   Also, you can use the |data| attribute to prefill the <datalist> from
an XML file.

   I'm going to skip the rest of the sections.

FINAL THOUGHTS:

1) DOM support for HTML Forms definitely needs to be improved to make
certain tasks easier. (I suspect such improvements will be needed
regardless of whether XForms-Tiny prevails against WF2.)

2) The best part of XForms-Tiny is that it give people the ability to
write complex formulas in a simple, easy to understand format. I would
suggest you submit your ideas on simple formulas in various attributes
for inclusion in the next iteration of Web Forms (Web Forms 3.0).
However, as I demonstrated above, the simple formulas used above do not
require significant scripting, and are therefore not a sufficient reason
to delay Web Forms 2.0.

3) XFT has a few nice features (like the formulas), but it's mostly
redundant when compared to WF2 and in many cases is far more limited in
its capabilities and fallback.

4) By the way, there is a pure Javascript implementation of the WF2
repetition model. Check out the following link:

http://weston.ruter.net/projects/repetition-model/

   The Solar System example shows the WF2 repetition model being used
without tables.

Received on Thursday, 18 January 2007 03:58:29 UTC