Re: About the Web Forms 2 proposal

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