Re: About the Web Forms 2 proposal

On Fri, 27 Apr 2007, Sebastian Schnitzenbaumer wrote:
>
> XForms Transitional has the notion of relevant [...], Web Forms 2.0 does 
> not.

XForms Transitional's "relevant" is equivalent to HTML4's "disabled" 
insofar as I can tell; or possibly equivalent to HTML5's "irrelevant" 
attribute (which isn't in WF2 but is in WA1).


> XForms Transitional [...] introduces an expression syntax, Web Forms 2.0 
> does not.

WF2 doesn't, because it has not been shown how it could work. We spent 
significant time and resources trying to find a way to make it work.

There have been a number of comments sent regarding XForms Transitional's 
expression syntax explaining why it doesn't work, or is not adequately 
defined for interoperability. It has not been shown to be a workable 
solution. Even members of the XForms working group have suggested that it 
may not be a good solution!


> An expression syntax and the relevant property go towards XPath 
> expressions and the binding mechanisms in XForms.

Not really. The expression syntax, as defined, doesn't really go any 
further towards XPath than, say, JavaScript.

But in any case this is a red herring; XPath is a technical-level detail 
of XForms, not an architectural aspect. The HTML working group's chartered 
goal is to ensure that our language has architectural compatibility with 
XForms; it is not our chartered goal to make our language go towards the 
technical decisions made by 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?

Actually Web Forms 2.0 has a range control, and it is backwards 
compatible, with graceful fallback in legacy browsers.


> Expression syntax and relevant are similar in thought. They go a little 
> further than incremental improvement.

The 'relevant' feature is available in the proposed HTML5 specs today, as 
noted above.

The expression syntax is only available using scripted events, but there 
has not yet been a workable solution proposed for addressing the concept 
of declarative relationships and declarative attribute values within the 
constraints of our proposed design principles. (If there had, Web Forms 2 
would probably already have it integrated.)


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

The needs of graceful degradation, implementability in the face of legacy 
content, and of finding pragmatic solutions to problems that web content 
faces today far outweigh any aesthetic concerns in the language design.


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

Efforts to migrate authors to use different techniques for solving the 
same problem are extremely time consuming. As a community, we have limited 
resources to put forward to changing world views. We should conserve those 
for the truly important education efforts, such as getting authors to 
write accessible, media-independent markup, rather than on trying to 
change authors from using one form of syntax to another.

Note that even if we add new syntax, browsers, and thus the specification, 
will regardless have to support the old syntax forever. So it doesn't 
actually simplify anything, it only makes it more complicated.


> The first assumption is whether we really want a migration with XForms 
> over time.

Who is "we"?


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

Any plan that involves at some point not following the proposed design 
principles (which include forever having graceful degradation and ensuring 
that user agents of the latest spec can always render all legacy content) 
is, in my opinion, doomed to failure in the market. I am not really 
interested in such a plan. I would posit that many people on this working 
group aren't either, given the broad support that the design principles 
have and that the WHATWG work so far has had.

Backwards compatibility isn't a fad that a group of mad Web-Forms-2 
proponents suddenly support and which they will forget later. It's a 
fundamental requirement for any successful technology.

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

Received on Friday, 27 April 2007 01:38:30 UTC