[whatwg] Web Forms 2.0 - what does it extend , definition of same,relation to XForms, implementation reqs.
ian at hixie.ch
Mon Jan 10 06:38:15 PST 2005
On Tue, 4 Jan 2005, Bill McCoy wrote:
> 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
> 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".
I'm not really sure what you mean by that (mainly because I never really
understood the term "Street HTML").
GMail is certainly not an extreme example of what the future holds for Web
applications. In fact, it's quite primitive, being not that much more
advanced than other Web mail applications such as Hotmail, which have
existed for years.
> 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
> scenarios, with little to no "semantics available in HTML".
It's not WHATWG who are heading "down the web application path with the
least-common-denominator of today's popular browsers" -- it's the authors.
Believe me, we'd be the first to have a party if WinIE6's market share
became insignificant. Mozilla (for instance) has provided XUL for writing
Web applications for _years_. There is basically zero demand for it. The
first question authors ask when XUL is suggested is "does it work in IE?".
And yes, Web authors today are quite bad at using HTML's current
offerings. I see no reason to believe they'd be any better at using (say)
XForms. Just look at the Windows shareware market -- hundreds if not
thousands of extremely badly written applications exist, just like the
thousands of badly written Web applications. I don't think I'd find insane
imperative, so debugging it is just a matter of walking through the code!
> I'm speaking from experience here: touch up a photo on Yahoo!Photos or
> was nevertheless necessary to get the job done.
Indeed. WHATWG aims to simplify some of this by providing more convenient
What should systems like Yahoo!Photos be implemented in, if not HTML?
> On a more mundane note, look at the prevalent table abuse to create
> precise layouts. Inferring semantics from fixed-layout HTML is
Exactly -- that's why WHATWG wants to let authors use new features in HTML
to mark up those semantics instead of hiding them in JS.
Note, by the way, that the use of tables for layouts is mostly due to the
difficulty in making the prevalent Web browser render pages as desired
using the right solution (CSS). Again, authors demand that their pages
work in default installs of the prevalent Web browser, so whatever
solution we (as an industry) provide, it has to be compatible with that.
This is the reason for WHATWG's backwards-compatibility goals.
> 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.
If better solutions to the rich Web app problem are successful, I will be
very happy. However, I haven't seen the migration of which you speak. If
anything, the migration I've seen is from traditional fat-client apps to
Web-based, centrally deployed HTML apps.
> 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'm not very familiar with the C++/C case, but if the parallel holds, then
the alternative to C++ would not have been Objective C, but simply staying
with C itself.
> It is no accident that C# is not backwards compatible with C
C# is a new language. It's lack of compatibility with C is no more
surprising than Perl's. The right parallel here is C++.NET, which _is_
backwards-compatible. Microsoft have made significant efforts to make it
possible to integrate existing C and C++ code with their .NET platform.
> And in this case I think it's clear that "Street HTML" for building rich
> interactive applications is an even worse starting point than C was for
> building reliable, OO software.
Which aspects in particular do you feel make it a bad starting point?
> The fact that Microsoft has already moved on from DHTML to XAML/Avalon
> suggests that history may not repeat itself
Microsoft dropping DHTML has, IMHO, nothing to do with technical merit. It
is purely a business decision -- DHTML is a medium they don't control,
XAML/Avalon is a medium they _do_ control. For Microsoft, requiring the
entire industry to drop DHTML and move to Avalon is a very bold and risky
decision, one that is _not_ guarenteed to succeed.
Microsoft were faced with a three-pronged problem: their core platform
(the Windows API, which has remained largely backwards compatible since
the mid 80s) was threatened by the DHTML platform, which they were to a
large extent responsible for creating; the DHTML platform was based on
open standards in a way that made it relatively easy to reimplement; and
the DHTML platform was founded in a world that made the operating system
(Microsoft's core business) irrelevant.
The only way to respond to this was to create a platform that had the
advantages of DHTML, but was Microsoft-specific and tied to the OS --
These business reasons don't apply to us. We don't have to risk everything
by breaking backwards compatibility.
> I'd love to see us all getting together to help create a unified
> standards-based approach to building Web applications that can move the
> industry ahead, building on key prior work (e.g. XHTML, SVG, XUL/XBL
> concepts, and, yes, XSLT and XForms) rather than trying to reinvent the
Web Forms 2 is based on XHTML and is intended to be implemented and
extended using XBL. Web Apps 1.0 (the other WHATWG draft) is similarly
based on XHTML, and is intended to integrate with SVG.
I don't think we are as far from what you want as you think we are.
> Fundamentally, I fail to see why enterprises should be expected to keep
> hacking applications onto HTML forms, with or without WF2 extensions.
They shouldn't. If people swiched to using XForms tomorrow, or even today,
then that would be great, and WHATWG would not be needed.
It's not WHATWG who are demanding that things work with HTML. It's Web
authors. WHATWG is merely responding to the demands we are hearing.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg