- From: Håkon Wium Lie <howcome@opera.com>
- Date: Thu, 4 Sep 2003 12:44:03 +0200
- To: Mark Birbeck <Mark.Birbeck@x-port.net>
- Cc: "'Wanda Cox '" <co.wanda@apple.com>, "'w3c-ac-forum@w3.org '" <w3c-ac-forum@w3.org>, "'team-xforms-review@w3.org '" <team-xforms-review@w3.org>, "'www-forms-editor@w3.org '" <www-forms-editor@w3.org>
Also sprach Mark Birbeck: > [I'm aware that your posting is part of a formal procedure, and not for > soliciting comments, but I feel that one of your central points is more an > issue of presentation of the spec, than of the spec itself, so I hope you > don't mind my comment.] In light of Roger Cutler's recent request for more exciting messages on this list, your comments are most welcome :-) > > Claim 3: XForms has striven to improve authoring. > > Counterclaim: XForms is, in our experience, orders of magnitude harder > > to author than HTML forms. For example, compare ... > > The spec has not focused on showing how to make forms simple, but that > doesn't mean it isn't possible. [example and arguments cut] > It would be difficult to argue that this is hard to learn! On the contrary, > the fact that there is not a line of script in sight, should make this a > breeze for most web programmers to pick up, make it quicker (and more > accurate) to test, and easier to deploy across platforms. By developing and standardizing library of "form functions", JavaScript can also be removed without using XForms. Things to note in the example below: * Does exactly the same as the XForms example, except that it works _right now_ in good XHTML+CSS+JS browsers. * No namespaces. * No XPath. * Fewer elements (ignoring those that were omitted from the XForms example, anyway). * Two event handlers, but just referring to a function in a generic library. * Easier to author, since it doesn't use any new technologies and authors are therefore already familiar with it. <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Hello, World!</title> <script type="text/javascript" src="library.js"/> <style type="text/css"> input[readonly] { border: none; background: transparent; color: inherit; font: inherit; display: inline;`width: auto; text-align: right; } </style> </head> <body> <form action=""> <p> <label> Choose a Greeting <select name="greeting" onchange="propagateValue(event)" size="1"> <option value="Hello">Hello</option> <option value="Goodbye">Goodbye</option> </select> </label> </p> <p lang="fr"> <label> Choissisez une Salutation <select name="greeting" onchange="propagateValue(event)" size="4"> <option value="Hello">Bonjour</option> <option value="Goodbye">Au Revoir</option> </select> </label> </p> <p> <input name="greeting" readonly="readonly"/>, World! </p> </form> </html> I can sympathize with the desire to remove JavaScript. Indeed, I argued for several features in CSS (e.g. hover effects) on the basis that they replaced JavaScript. However, I don't see that replacing JavaScript with XPath is a huge step in the right direction as writing XPath expressions is very similar to programming. XPath may not be Turing-complete at this stage, but seem to be heading quickly in that direction. What I see is that introducing XForms on the web represents a huge complication for authors and tool makers while not achieving much beyond what can be already be achieved interoperably today. Opera Software has been working on an XHTML module which would add some functionality from XForms (e.g. basic data typing and XML submission) without introducing large numbers of extra dependencies. We hope to continue this work in cooperation with W3C and its members. -h&kon Håkon Wium Lie CTO °þe®ª howcome@opera.com http://people.opera.com/howcome
Received on Thursday, 4 September 2003 06:44:16 UTC