- From: Dave Raggett <dsr@w3.org>
- Date: Mon, 26 Mar 2007 15:31:33 +0100 (BST)
- To: Anne van Kesteren <annevk@opera.com>
- cc: Ian Hickson <ian@hixie.ch>, Sebastian Schnitzenbaumer <sebastian@dreamlab.net>, public-html@w3.org
As a follow up, someone in the forms working group suggested that it would be practical to prohibit custom functions and to instead rely on a small set of prefined functions for which the semantics can be clearly defined. The use cases I have looked at have only needed simple mappings from field values to prices etc. that can easily be expressed as associative arrays, e.g. price[productCode]. Some use cases: - Ordering pizza where the total price is computed from the pizza size and the number of toppigs, and the price per topping depends on the pizza size. - Application form for a loan where you are asked for details of your previous home if you haven't been at your current residence for more the 3 years. - Wizard for ordering a custom desktop PC online, where the wizard takes you through a series of choices and shows you the running total and a summary of the specification so far. - Employee expense claim form used as part of a workflow process that is signed off and then paid. This form involves intercolumn calculations in a repeated data set. - Tax form with lots of sections that are revealed as appropriate according to how you have filled out earlier sections All of the above can be represented in a declarative way without the need to resort to scripting. The ability to hide section of the form until needed makes the process of filling it out less intimidating. Simple expressions make it easy to define the conditions under which different sections of markup are relevant and should now be shown. Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett On Sun, 25 Mar 2007, Dave Raggett wrote: > On Sun, 25 Mar 2007, Anne van Kesteren wrote: > >> On Sun, 25 Mar 2007 20:17:54 +0200, Dave Raggett <dsr@w3.org> wrote: >>> 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 >> >> Note that functions must be side-effect free and avoid >> introducing dependencies on form fields other than those >> passed via the function's arguments. This is needed to >> ensure that the expression can be statically analysed. >> >> Doesn't help an implementor much. It seems you still haven't addressed the >> original concern various people expressed either on this mailing list or >> #html-wg. > > How so? > > We all know that it is impractical to analyse turing complete code, and > browsers wisely don't try to do so. If your scripts don't behave as you > expect, it is generally up to you as the programmer to sort it out. > > For the simplest case authors wouldn't need to write functions so that > problem wouldn't arise. Any functions that the editor provides would have > been written by experts and subject to testing to ensure > that these functions abide by the rules. > > 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. > > 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. > > The same problem occurs if the editor saves the semantics for the event > handlers in a non-standard declarative format since this will prevent other > editors who don't know about that format from being able to offer an > effective service to non-technical users. > > I think this is a critical question for the HTML working group. I am striving > to provide a technically sound solution for extending WF2 with declarative > expressions, but if the working group isn't willing to consider this, I would > like a decision earlier rather than later. > > Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett >
Received on Monday, 26 March 2007 14:32:12 UTC