- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 10 Jan 2005 14:38:15 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 10 January 2005 06:38:15 UTC