declarative expressions in HTML5

(Messages replied to herein were sent to several lists, including WHATWG,
public-appformats, and www-forms, but to reduce cross-posing I've only 
sent the reply to public-html and bcc'ed the original authors. If you 
aren't subscribed to public-html but wish to reply, please feel free to 
replace public-html in the cc list with another list. Thanks!)

Conclusion: I haven't added declarative expressions to HTML5, as there 
does not appear to be a suitable, high-level, powerful expression language 
that is significantly simpler than scripting, and the benfits of 
introducing a new language are minimal and far outweighed by the costs. 
Furthermore, there seems to be no particular interest in this feature from 
the wider community and even within the small group of people who have 
expressed an interest, opinion seems equally split between people in 
favour and people against.


On Thu, 19 Oct 2006, Dave Raggett wrote:
>
>      http://people.w3.org/~dsr/forms-lite/
> 
> [...] Here is a summary of the new attributes and what they do:
> 
>  calculate
>    This is used with the input element for spreadsheet like
>    formulae for calculated fields, e.g. calculate="x+y" where x
>    and y are names of other form fields. The forms-lite library
>    takes care of the dependencies between calculated fields using
>    a topological sort.

According to this example:

   http://people.w3.org/~dsr/forms-lite/13/index.html

...the calculate="" attribute can execute arbitrary JavaScript, which 
implies that the dependencies can't be calculated, since one would need to 
perform a statistical analysis of the JavaScript to do so, and doing that 
is impossible (it could, e.g., depend on the result of an unpredictable 
request to a server).

If the dependencies can't be calculated, then this seems no better than, 
e.g., setting the value directly using onforminput="" instead of 
calculate="". If we disallow JavaScript then frankly the power of this 
system is likely to not be enough to really benefit authors enough to 
justify the cost to implementors -- authors seem to prefer imperative 
calculations in this kind of thing over declarative expressions.


>  pattern
>    This is used with the input element to constrain input to
>    match a regular expression.
>
>  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.
> 
>  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.
>
>  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. The library can be customized to alter
>    the user interface associated with the range control.

These are all now in HTML5.


>  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 &gt; x"/> which says that this field value
>    must be greater than the value of the field named "x".

We also need to provide a string explaining the problem, otherwise the UI 
will be somewhat suboptimal. One can do this with script, e.g.:

   <input name=y type=number onforminput="
     if (y.value < x.value)
       setCustomValidity('y must be greater than or equal to x')
   ">


>  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.

If these can call JavaScript, it doesn't seem to gain us much over what we 
have now:

   onforminput="required = x.valueAsNumber < 10"


>  relevant
>    This may be used on HTML input and fieldset elements to
>    indicate when the associated group of fields is relevant.
>    It is an expression similar to validate. The library
>    dynamically adds or removes class values so that the style
>    sheet can be used to hide the fields when they are shown
>    to be irrelevant. Such fields are not included when the
>    form is submitted.

This is basically the same as "disabled", which for historical reasons 
doesn't take an expression, but you can use onforminput="" again to solve 
this use case, e.g.:

   onforminput="disabled = y.value < x.value"


>  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've removed the repetition model because there are so many conflicting 
requirements for repetition mechanisms that no single system seems capable 
of addressing a majority of them.



On Fri, 19 Jan 2007, Dave Raggett wrote:
> 
> However, having to write and debug a new script for each new page soon 
> gets tedious. Declarative approaches are much easier to write and much 
> better suited as a target for authoring tools.

I don't really see why onforminput="value = Math.sin(theta.value)" would 
be easier to debug than the equivalent expression (how does one do 
sines?). The script is imperative, but basically looks like an expression 
anyway. It's only when you get into things that you can't do with 
expressions that debugging scripts becomes harder than simple expressions, 
but then on the other hand expressions can't do those things (by 
definition), so that's not really an argument against script.


> The declarative nature of the type, min, max, step, required, relevant, 
> pattern, validate and calculate attributes in XForms-Tiny also makes it 
> practical to automatically generate server side scripts for validating 
> submitted data, which you would otherwise have to write separately from 
> the client side code, with all the risks that that entails.

If you're going to have the client and server code generated from a 
separate constraints definition, it doesn't seem any easier to generate 
expressions in a declarative language than expressions in an imperative 
language.


On Sun, 25 Mar 2007, Dave Raggett wrote:
> > 
> > The new spec doesn't change the UA requirements, so you still (as far 
> > as I can tell) require UAs to do static analysis of turing complete 
> > code, which, here, reduces to the halting problem. (All you've done is 
> > made such cases non-conforming, but that doesn't affect the UA at 
> > all.)
> 
> I have introduced a grammar for a subset of ECMA 262 r-value expressions
> together with additional constraints that ensure that the expressions can be
> statically analysed. See:
> 
>   http://www.w3.org/2007/03/XForms-Transitional/#expr-syntax

This still allows escapes into arbitrary script (through functions), so 
the problem still exists.


> > There are other problems, too, such as how to handle fields whose 
> > exact lists of dependencies themselves depend on other field, e.g. 
> > because the calculate="" field does something like:
> > 
> >   calculate="document.forms[0][document.forms[0].field.value] + 1"
> 
> This isn't permitted and would result in an error when parsing the 
> expressions.

Such an expression could be placed in script, however.


> > It's also unclear to me how UAs should handle cyclic graphs (which 
> > can't be sorted topologically) or graphs whose dependencies are either 
> > truly or apparently random (e.g. because the field used depends on the 
> > return value of an XMLHttpRequest call to a remote server).
> 
> An exception is raised when cyclic dependencies are detected during the 
> sort of fields found to depend on a field whose value has just been 
> updated by user input. The dependencies must be statically analysable 
> and that rules out the use of a function or array access to obtain the 
> name of a field, including the use of XMLHttpRequest.

How can you know, without analysing the script?


> The ability to access arrays and to call functions provides considerable 
> flexibility, but places the responsibility of the scripter to avoid 
> shooting himself in the foot. This has been the case for scripted event 
> handlers since the introduction of scripting for HTML.

If all this adds is dependency sorting and expressions with the ! + - * / 
% && || < <= == != > and >= operators without using the ".value" suffix, 
it's unclear what the real benefit is. If ordering is an issue on a form, 
one can trivially just manually place all the calculations in one function 
called from the form's onforminput="" event handler.


On Sun, 25 Mar 2007, Dave Raggett wrote:
> 
> We all know that it is impractical to analyse turing complete code

It's not impractical, it's provably impossible. (All the more so in JS 
where one can end up eval()ing server-returned unpredictable strings that 
vary with each execution.)


> You might say "What's wrong with event handlers?. Everyone in the HTML 
> WG is very comfortable with writing scripts for event handlers, so 
> what's the problem?"
> 
> Well we have a duty of care to the rest of the population who don't know 
> and don't care about scripting. If we ignore that duty then the market 
> will make a correction. HTML will be sidelined as a delivery format and 
> won't be an editing format.

It is unclear to me that the set of people formed from the intersection of 
the set of people for whom simple scripting of expressions is inaccessible 
and for whom these simple expressions are acceptable is non-empty. We 
would have to show that this set is not only non-empty but a significant 
portion of the authoring population to make this a good idea.


> In IRC you suggested that editors could recognize the scripts that they 
> generated. That's true, but leads to the undesirable situation where you 
> can only edit a document if it was created by that editor. Switching 
> back to a text editor isn't an option for people who don't know about 
> HTML, CSS or JavaScript.

It is unclear to me that people authoring forms complex enough to have 
these equations are going to be using WYSIWYG editors as opposed to text 
editors, but even if that is so, it seems like a better solution would be 
defining a common recognisable syntax rather than a whole new expression 
language, thus allowing editors to share pages.


> I think this is a critical question for the HTML working group.

I do not think that this is a question that is of great concern to the 
wider community. In four years, we have only received feedback of this 
nature from a small handful of people, all of whom know each other and 
share a common agenda.


(I have omitted from this response replies to e-mails of a process nature 
and e-mails arguing against the feature.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 28 October 2008 08:33:49 UTC