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

[Ian Hickson]

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 
> happen.
>
> 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 
> achieve any kind of rich user experience, you end up in JavaScript-heavy 
> 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 
XPath any easier to follow than insane JavaScript. At least with JS it's 
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 
> Ofoto and you will see another instance of ridiculous JavaScript that 
> was nevertheless necessary to get the job done.

Indeed. WHATWG aims to simplify some of this by providing more convenient 
APIs to reduce the need for ridiculous JavaScript.

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 
> challenging, never mind JavaScript.

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 -- 
namely, Longhorn/Avalon.

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

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.   `._.-(,_..'--(,_..'`-.;.'