W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2005

[whatwg] Web Forms 2.0 - what does it extend , definition of same, relation to XForms, implementation reqs.

From: James Graham <jg307@cam.ac.uk>
Date: Tue, 04 Jan 2005 15:29:16 +0000
Message-ID: <41DAB64C.1070803@cam.ac.uk>
Bill McCoy wrote:

>I find it odd that some WHATWG members argue that transmitting arbitrary XML
>data over the wire to clients is a bad idea (
>http://ln.hixie.ch/?start=1064828134&count=1 )given that the solutions
>already widely employed in Street HTML - encoding data in JavaScript arrays
>and other tricks - are so much less "Semantic Web" friendly. To pick an
>extreme example, Google folks admit that search-indexing a Gmail screen
>would be extremely challenging (they themselves index the raw data of
>course, but that's the whole point - it's much easier to process structured
>data before it's been compiled into a presentational form that is partially
>programmatic code). The WHATWG proposals to promote scripting, rather than
>declarative markup, as the basis of forms data binding and validation, and
>to dispense with an XML-based data model separate from presentation, would
>seem likely to worsen this situation by leading to more Gmail-like
>JavaScript-centric web applications.
>  
>
It's not only an extreme example, it's a terrible example. Google have 
repeatedly shown that they have no interest in using the semantics 
available in HTML, let alone whatever additional complexity is provided 
by XForms - just see any Google search results page. This is clearly not 
an inability to understand the benefit to the client of good markup and 
so must be a conscious decision on the part of Google. So the fact that 
GMail is hard to index is just as likely evidence of malice as it is 
evidence that better data/presentation separation is needed.

Even allowing that your example is misguided, I'm not sure I believe the 
rest of the argument either. In order to believe that HTML should be 
starved in order that XForms should flourish, you have to take the 
position that there will be a migration to XForms (and XHTML) from HTML. 
In order to believe that this will offer a significant advantage to the 
semantics of the web, you have to believe that authors will tend to use 
the new features offered by XForms in the way that they are designed to 
be used. In practice, I'm thoroughly unconvinced of the first and 
skeptical of the second.

At the moment, there is simply _no_ way of migrating away from "street" 
HTML. XHTML is fundamentally incompatible with "street" HTML because the 
processing requirements of HTML are satisfied by a negligible proportion 
of all HTML documents. XHTML is not supported in any meaningful way by 
the world's most commonly used web browser. There are few existing CMS 
solutions that are able to produce XHTML reliably, let alone arbitrary 
XML, and few users who understand the technical requirements of XML. The 
combination of all these factors makes it very hard to migrate away  
from HTML to anything that is not explicitly compatible with it.

Even if people could migrate away from HTML, it is doubtful that they 
would suddenly learn the benefits of sending semantic documents over the 
wire, nor the ability to understand complex specifications well enough 
that they would produce high-quality documents. I would expect that in 
XForms, as in HTML, if there is a way to hack a solution that 
looks/works as expected then authors will use that at least as often as 
they use the neat solution provided by the language.

The major advantages of the WHATWG specs over XHTML/XForms are
1) Backward compatibility. They can be used in situations where there is 
existing content that must be integrated and a limited migration budget 
(i.e. most real world situations)
2) Limited additional complexity. Because Web Forms 2 is close to HTML 4 
and, in particular, because it does not switch to a model in which 
everything is done declaratively, it is familiar to existing authors 
and, as a consequence, is more likely to be understood, adopted, and 
used in a way compatible with the specification.
Received on Tuesday, 4 January 2005 07:29:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:20 UTC