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

[Bill McCoy]

This is a response to the Dec. 10 call for final comments on the Web Forms
2.0 propoal.

1. The proposal is unclear about what it is extending. The proposal defines
Web Forms as "an extension to the forms features found in HTML 4.01's Forms
chapter" and that the "specification clarifies and extends the semantics put
forth in [HTML4]". Yet, the specification includes substantive extensions to
DOM and implications for CSS, neither of which are part of HTML4. The spec
also appears to cover browser-based rendering of CSS-styled/scripted XML. It
appears from the spec and charter that the intention of WHATWG is to define
Web Forms as an extension to what Opera calls "Street HTML", and defines as
"the real HTML that is used on the millions of sites on the Internet". In
other words, WHATWG appears to be proposing to extend the de facto Web
platform of HTML+CSS+DOM+JavaScript, as implemented by browsers prevalent
circa 2004, not just HTML. If so why not explicitly state this expectation?

2. So what is "Street HTML" anyway? Is the "outerHTML" property in or out?
What are its error handling rules, exactly? Is client-side XSLT part of the
platform? WHATWG proposes to add a couple dozen new HTML attributes, several
new HTML elements and DOM interfaces, a bunch of new DOM interfaces and
attributes, and changes to the content model and semantics of existing HTML,
CSS, and DOM facilities. Are you really proposing to take an ill-defined
spec and bolt on all this additional complexity? Wouldn't it be more
appropriate to first, as constituting three of the four leading browser
manufacturers, clearly define what is this "real HTML" platform? You would
be doing the community a real service if you tackled defining the existing
foundation before proposing to in effect add-on a another story.

3. Section 1.4 on "Relation to XForms" is confusing. Terms like "everyday
Web browsers" and "typical Web browsers" are ill-defined. Also the statement
that XForms "has not been widely implemented by those browsers" seems odd in
this context: XForms is a new spec and the proposed Web Forms 2.0 has not
been implemented yet either. And again WHATWG represents the 2nd, 3rd, and
4th most popular browser manufacturers, and XForms has already been
implemented as a plug-in to the #1 browser, so what this seems to really
amount to is "we don't want to implement XForms, we want to implement this
other thing, Web Forms 2.0, instead". If that's your position, why not just
say so? Also the comment about "dependencies on technologies not widely
supported by Web browsers" in this section and the introductory comment
about not requiring "support for other technologies such as XPath, XML
Schema, or XML Events, as these are not implemented in typical Web browsers"
seem strange circa 2005. For example XSLT builds on XPath and as such XPath
(along with XSLT) is already supported in the two most popular web browsers.
XML Schema is part and parcel of SOAP, and is for example already
standardized in Mozilla/Firefox and through .NET is available in IE
platform. So it seems that these technologies are already widely supported
and that this should be a non-issue in the decision whether or not to
support XForms. And of course XForms is designed for client-side execution
as a major use case and client-side XForms solutions are being commercially
deployed so at a minimum your diagram is confusing, as it should at least
show that server transcoding is a backstop for XForms support, not the only
path.

4. This is only indirectly covered in the spec, but the assumption that the
spec should not dictate a plug-in based implementation for Internet Explorer
is difficult to understand, especially if an HTC-based implementation is
deemed acceptable. Shortcomings of HTCs have been widely discussed in this
forum and elsewhere and I know of no widely-used production software that
uses an HTC-based approach to extending Internet Explorer. Security
recommendations for corporate and end users are trending to disable "Binary
and Script Behaviors", and it would not be surprising to see this be the
default in the future, so support for document-based HTCS may become
"doesn't work" or at best devolve to the same security model as for
plug-ins. And the model for users to grant one-time permission to install a
trusted plug-in is well-understood and there are examples of widely-adopted
commercial-grade plug-ins to Internet Explorer (e.g. Macromedia Flash, Adobe
Reader). Rejecting XForms because it would (perhaps) require a plug-in based
implementation for Internet Explorer seems odd (especially so when XForms
building-block technologies like XPath and XML Schema are already present in
this browser platform). Alternatively, if you believe a server-based
implementation of Web Forms 2.0 support for nonsupporting browsers is
acceptable (as your demos page seems to imply) then adopting XForms would
seem to make much more sense: a well-defined declarative XML-based language
is well-suited to server transformation (as your section 1.4 states).
Whereas Web Forms 2.0, being a script-intensive solution built on an
ill-defined non-XML language is clearly not going to be nearly as easy to
handle in server-based workflows. Indeed one of the world's largest web
sites maintains a large-scale Windows server stack merely to run MSHTML
server-side. While keeping web documents arcane and difficult to process may
be a source of commercial advantage to browser manufacturers it doesn't seem
like a great solution for the industry as a whole.

--Bill McCoy
Adobe Systems Incorporated
bmccoy at adobe.com