[whatwg] Features in XForms Tiny that Web Forms 2 lacks

Fri Feb 16 19:15:14 PST 2007

Anne van Kesteren wrote:
> I went through the examples on http://www.w3.org/2006/11/XForms-Tiny/ to  
> find out which features "XForms Tiny" has that Web Forms 2 currently does  
> not have. I'm not sure how these features are supposed to be implemented  
> (saying this up front as Hixie already had a few interesting questions in  
> #webapi). This list might not be complete.

   With regards to the actual attributes, I think it's pretty complete,
save explicit mention of the |name| attribute on <fieldset> elements.

> A calculate="" attribute which takes an ECMAScript expression which  
> evaluates to a value for the form control.

   Yeah, it's supposed to be a Javascript expression, but it uses
simplified names for the form values, some of which are shorthand for
entire radio groups and whatnot. This simplified manner of referring to
control values is the most valuable part of these expressions. Without
them, the various attributes aren't much better than using event
attributes...

WF2:
| <input name="sum" onforminput="value = (+x.value) + (+y.value)">

XForms Tiny (without shorthand):
| <input name="sum" calculate="(+x.value) + (+y.value)">

   When you consider a function that can take these shorthand formulas,
these attributes become only mildly useful:

WF2 (with a special function) :
| <input name="sum" onforminput="value = calc('x + y')">

XForms Tiny:
| <input name="sum" calculate="x + y">

   Still, using an event is a bit more cumbersome. If we can figure out
when these attributes are evaluated in relation to other events and
whether or not the evaluation can be canceled, they could make it a lot
easier to do complex forms in HTML. I'm thinking these attributes could
be evaluated after |onformchange| and their evaluation would be canceled
if the event is canceled.

> A constraint="" attribute which takes an ECMAScript expression which  
> evaluates to a boolean which determines whether or not the control is  
> valid.

   This one is actually quite useful, due to the complexity of setting
validity programmatically:

XForms Tiny:
| <input name="y" [...] constraint="y > x"/>

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

   Thought: Would "valid" be a better name for this attribute?

> A needed="" attribute which takes an ECMAScript expression which evaluates  
> to a boolean which determines whether or not the control is required.  
> (This basically allows more than than the current required="" attribute in  
> the Web Forms 2 specification.)

   Since this is really just a conditional |required| attribute, why not
just modify |required| to take Javascript expressions, but make the
value "required" a synonym for "true"? That way we could still use
attribute minimization for situations where we want |required| to be
true, but we could also use formulas.

> A relevant="" attribute which takes an ECMAScript expression which  
> evaluates to a boolean which determines whether the control is "relevant".  
> This attribute also applies to <fieldset> elements.

> If you have a repeated set of form controls there's a way to associate a  
> single label with the "same" control in each set of form controls which  
> you can then style based on one or more of the form controls in the  
> repeated set of form controls being invalid (or not meeting another  
> condition I presume).

   They're doing this by overloading |for| to apply to names as well as
IDs. This could encourage web authors to break compatibility with legacy
user agents because they may start using the name instead of the ID in
situations unrelated to the repetition model.

   Another thing is that it changes the semantics of the <label>
element, changing it from a label for individual controls to a label for
collections or columns of controls. Why not just allow <th> elements to
be selected by :invalid if controls in their associated row or column
are invalid? It might encourage use of some of those little known table
attributes...

   (It should be noted that the XForms Tiny repetition model doesn't
allow for a <label> per control. Thus, there can only be one label for
all repeated controls.)

> http://www.w3.org/2006/11/XForms-Tiny/14/Overview.html is also an  
> interesting one. I'm not sure how to summarize its functionality though.

   This is about using <fieldset> elements to create a data hierarchy.

   The first issue with this in order to take advantage of the
hierarchy, you have to use periods in formula. However, periods can
already be used legally in the |name| attribute, so this brings up
backwards compatibility issues.

   The second issue is that this encourages the reuse of markup in a way
that does not gracefully degrade. If you have multiple controls in
different <fieldset> elements with the same |name|, you have to know the
order of the controls in the document to determine which value is which.
It makes way more sense to just put a prefix in the |name| value.