- From: Sebastian Schnitzenbaumer <sebastian@dreamlab.net>
- Date: Fri, 27 Apr 2007 02:03:24 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: Anne van Kesteren <annevk@opera.com>, public-html@w3.org
This is work for the forms task force. I do see that Web Forms 2.0 was designed with XForms in mind. XForms Transitional has the notion of relevant, introduces an expression syntax, Web Forms 2.0 does not. Both approaches overload the input element for backwards-compatibility. An expression syntax and the relevant property go towards XPath expressions and the binding mechanisms in XForms. Take the range attribute in both approaches, and the range element in XForms. Couldn't we also introduce the range element in HTML5? With strict backwards-compatibility no, but then, how do we introduce new features, avoiding tag soup? Expression syntax and relevant are similar in thought. They go a little further than incremental improvement. Those approaches in XForms Transitional might not be as technically solid yet as in Web Forms 2.0, but there is a Task Force for this, and more important is the positioning of the technology in terms of moving up in the richness of expressing the authors intent. A range element has the potential of being extended over time to become richer. An overloaded input element with a range attribute however is a near dead-end, you can continue to add more attributes, but it becomes messy. Shouldn't we also encourage authors to migrate to a co-existing range element next to the range attribute with same semantics over time, so that later we can deprecate the range attribute and continue on with the richer range element with more semantics? Similar, shouldn't we start to introduce a simple expression syntax and the relevant attribute to start introducing the semantics of the richer binding mechanisms from XForms in HTML, slowly moving away from scripting in always re-occuring field inter-dependencies and calculations? This is architecture, and it is not about 'features XYZ in Web Forms 2.0 is broken because...'. The first assumption is whether we really want a migation with XForms over time. If the answer is yes, we have to think about an architectural strategy of introducing new features that have made XForms successful over time in HTML. This means that we eventually leave backwards-compatibility behind and in the meanwhile follow a parallel approach of backwards-compatible incremental improvement and introduce new semantics that can be enriched over time to further close the gap between HTML and XForms. - Sebastian Ian Hickson schrieb: > On Thu, 26 Apr 2007, Anne van Kesteren wrote: > >> Web Forms 2 has taken as much features from XForms as possible to the >> extend that it is feasible to integrate the XForms features in a model >> that needs to be compatible with deployed HTML content and HTML >> implementations. >> > > This bears emphasis. The whole point of the Web Forms 2 work was to take > the XForms architectural ideas and make them available to HTML authors, to > help the transition to XForms (the introduction section even has a diagram > showing this). > > Web Forms 2.0 was originally called XForms Basic; we changed it at the > request of the XForms working group. > > Most (all?) of the ideas in XForms Transitional either were or are still > in Web Forms 2.0. The ideas that are no longer there, or that have changed > significantly since their original introduction, changed in response to > community feedback to address issues with the proposals. These *exact same > issues* have now been raised on XForms Transitional. > > > >> This is why I think it would be useful if the people who prefer XForms >> Transitional because Web Forms 2 doesn't meet the architectural goals of >> XForms clarify what changes they would like to see made to Web Forms 2 >> that would bring it closer to those goals. >> > > I would highly encourage the XForms Transitional proponents to send review > comments on Web Forms 2.0 exactly as Anne suggests. The reverse has > already happened. It will be very difficult to make forward progress > without everyone fully engaging in this work -- and this means that > reviews have to go both ways. > >
Received on Friday, 27 April 2007 00:12:18 UTC