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

[Håkon Wium Lie]

Also sprach Bill McCoy:

 > To be clear, I'm not hypothesizing a migration away from HTML for vanilla
 > "web page" content or simple web forms; I agree, it ain't gonna happen. 

Given this realization (which I share), doesn't it also make sense to
maintain the HTML specifications? People will be writing HTML
documents and will turn to W3C for specifications. If what they find
there is outdated, they are less likely to come back for other stuff.
Therefore, W3C should maintain its core specifications (HTML and
friends) instead of starving them (to use James' fitting term). Error
should be corrected, common behavior should be encoded, and leaks
should be plugged.

 > But the expressed charter of WHATWG is "applications", and in the web
 > application domain I claim that GMail is not an extreme example of what the
 > future holds for "Street HTML". It's simply a fact that if you head down the
 > web application path with the least-common-denominator of today's popular
 > browsers, and want to achieve any kind of rich user experience, you end up
 > in JavaScript-heavy scenarios, with little to know "semantics available in
 > HTML". I'm speaking from experience here: touch up a photo on Yahoo!Photos
 > or Ofoto and you will see another instance of ridiculous JavaScript that was
 > nevertheless necessary to get the job done. On a more mundane note, look at
 > the prevalent table abuse to create precise layouts. Inferring semantics
 > from fixed-layout HTML is challenging, never mind JavaScript. And migration
 > from HTML (and from traditional fat-client apps) in the rich app space is
 > already happening with XUL, Flash apps and other rich-client approaches, and
 > XAML is looming.

It's an interesting argument. A couple of comments. The
"least-common-denominator" isn't that small. Over the last years, the
HTML/DOM/CSS/JS platform has established a significant cross-platform
platform for application development. The underlying code is not
always pretty, but I don't think there ever will be pretty code in all
places. Web languages will always be abused, even those that were
specifically developed to clean up the mess (WML and XHTML come to
mind).

 > I do, however, agree with your expressed advantages of WF2 over XForms
 > (backwards compatibility, not requiring a switch to a new paradigm). These
 > same advantages applied to C++ wrt C, and I happen to personally believe C++
 > set the software industry back half a decade vs. if (say) Objective C had
 > won.

I think we all agree that the benefit of new paradigms sometimes are
worth sacrificing backwards compatibility for. These situations are
known as revolutions, and the web itself is a prime example. Instead
of extending gopher, a new paradigm was introduced which changed the
world. (Interestingly, though, it still supported gopher through its
own URL scheme.) And, there was no way PNG could be built on GIF since
the whole point of the exercise was to get rid of the fundamental
patented algorithm. However, you can't have revolutions every day and
often it's better to extend the current specification. For example,
HTTP 1.1 is backwards compatible with HTTP 1.0, and CSS took great
care to not change the rendering of HTML documents in legacy systems.

When you want to make the world a better place by introducing some new
functionality, one of the first questions to ask is whether this can
be gently added to an exisiting solution or if you have to start from
scratch. There is not correct answer to this question, it's a
judgement call. I'm sure Adobe knows more about this than most
companies; deciding to switch to PDF from PS seems like one of those
moments.

It seems clear to me that W3C, in the past few years, have opted to
start from scratch more often than they should. XLink was developed as
a new way to encode links when HTML already had a deployed method for
describing them (the HTML WG refused to accept Xlink, showing healthy
resistance). XForms was developed without a clear consensus that the
deployed way of doing forms was broken. Indeed, I believe WF2 has
shown that it is possible to extend the current model and that the
significant costs associted with replacing it therefore can be
avoided. This should be good news for everyone, except those who have
vested interests in change for change's sake.

(This is probably a good place to state that I also believe there are
good use cases for XLink and XForms. Replacing HTML is not among them,
though.)

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome at opera.com                  http://people.opera.com/howcome