This is part of a series of cross-platform experiments in incremental extensions to HTML4 forms that provide a stepping stone towards the much richer capabilities in XForms. This particular experiment introduces a calculate attribute.
The calculated field is updated as result of an onchanged event on a dependent field, which occurs when the updated field loses the input focus. The calculation can be any JavaScript expression and may include field names from the same form, references to global JavaScript variables, and calls to functions defined by the Web page script. The label elements are for accessibility.
Please view the XForms-Transitional script for more details on how this works.
Here is the markup for the above form:
<form name="form1" onsubmit="false"> <fieldset> <legend>Simple calculation</legend> <label for="f1">X</label> <input id="f1" name="x" datatype="number"/> <label for="f2">Y</label> <input id="f2" name="y" datatype="number"/> <label for="f3">X + Y</label> <input id="f3" name="sum" calculate="x+y" datatype="number" readonly="readonly"/> </fieldset>
Before expressions are evaluated, field names are rewritten according to their type. Text fields remain as strings, but numbers and dates are evaluated as such, and this may result in an exception. An open question is exactly how to deal with the situation where one or more field references are to fields that are currently invalid. Note that field references can only be to fields in the same form. In the above example, the fields are declared as numbers. If the type attribute had been left out, the default type would be string. The JavaScript plus operator would have then acted as a string concatenator.
A topological sort is used to ensure that calculated fields are evaluated in the appropriate order taking into account the dependencies between them. This allows field calculations to be based upon other calculated fields. Cyclic dependencies are detected and reported as an error. If the calculation results in NaN (not a number) the field value is cleared.
When the calculation results in a fractional part, it would be worth providing a means to limit the number of digits shown after the decimal point. This would also limit the accuracy of calculations involving the values of calculated fields due to the lack of separation between the presented value and the value held internally by the field.
Note that the HTML4 readonly and disabled attributes may be used with calculated fields. The readonly attribute means that the field can only be updated by scripts, athough it can still receive the focus. Setting disabled prevents the field from being submitted and also prevents it from gaining the focus. Unfortunately, both Opera and Internet Explorer ignore the CSS color property for disabled fields.
How to deal with input fields whose calculated value has been manually overridden (as is possible on spreadsheets)? This suggests the use of an internal override flag on the field's object that suppresses the calculation of the field's value. The form reset operation should clear this flag.
It might be interesting to introduce an output element when the calculated value isn't to appear as part of the submitted data. This is essentially equivalent to an input element that is set to read-only and disabled. It is a little tricky to add new elements into the HTML DOM due to variations in behavior across browsers.
How to allow for non-ASCII characters as part of field names? This involves tweaks to the regular expressions used to identify field names in expressions.
Would it be helpful to update calculated fields whilst the dependent field still has the focus? This could be done on a keystroke by keystroke basis or after a brief period of inactivity.
Dave Raggett <dsr@w3.org>Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.