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

[J. Graham]

On Sat, 8 Jan 2005, Bill McCoy wrote:

> James,
>
> I basically agree with you. There are multiple paths to building apps:
> "Street HTML" (as Opera calls it) and (as you call it) "XML Soup". Modern
> browsers to varying degrees support both the HTML-centric and XML-centric
> approaches, just as Visual Studio support multiple languages. So I believe
> it's valid to discuss (in the topic of extending modern browsers) how much
> to push the one side vs. the other.

I have no doubt that the discussion is valid and hopefully useful to the 
various parties involved.

> Just as the decisions of people at Mozilla, Opera, and
> Apple (and of course Microsoft still) will be critical parts of creating the
> total value proposition around both HTML and XML-centric applications. I am
> merely pushing for you guys to make decisions in the interests of those
> users as you balance your efforts between HTML- and XML-centric
> capabilities, I don't give a hoot about technical merits in isolation.

As I understand it, one of the motivations for forming the WHATWG is that 
browser vendors felt increasingly marginalised at the W3C; the major web 
document format (HTML) had effectively been dropped and, even where 
vendors have put in the effort to implement the newer XML technologies, 
they have been widely ignored by the developer community. Now partially 
this is because the newer formats have largely not been implemented in 
Internet Explorer except, in certian cases, via binary plugins.

But the lack of interest in XML also it's because the web developer 
community really isn't prepared for the rigours of XML. By and large the 
community has the idea that (X)HTML documents should be editable in a text 
editor, that it should be possible to use low-effort solutions (like 
embedded PHP) to produce a dynamic site, that even sophisticated server 
side systems should function by passing strings containing content around 
and that browsers should be forgiving of whatever mistakes you make. Any 
XML based solution *requires* an entirely different mindset. One can't 
simply hack together functional pages with notepad and PHP for Dummies; 
one has to use sophisticated software that knows about elements and 
attributes rather than just strings. One has to ensure well-formedness 
(not to mention validity) at every stage. These tools don't even always 
*exist* - I can't think of a single mainstream weblogging tool that fits 
the needs of an XML environment (there are several non-mainstream tools 
that work well but none that has the ease of use or deployment requirments 
to compete with Movable Type / Wordpress / etc.).

I'm sure everyone here knows the pitfalls of HTML; the poor 
interoperability of different parsers, the inability to use content from 
different namespaces. So the web has dug itself into a hole. The problem, 
as I see it, is that the W3C leapt out of the hole and then gave up on 
everyone who was still stuck. Web Forms is an attempt to improve the 
experience for the rest of us, so that web applications get better without 
requiring the huge leap from HTML to XML. In doing so, it might make the 
smaller jump to proprietry solutions less appealing.

>
> I also agree "worse is better"... But this principle is always "... to a
> point". A toolbox doesn't just contain a hammer, even though a hammer is a
> "worse is better" solution to a lot of problems. We've all built a lot of
> great server-based HTML apps in recent years, but precious few of them
> deliver the user experience quality of a basic VB desktop app.

This may be true in some cases but for much of the time, a desktop app is 
really the wrong comparison. Lots of Web Apps are pretty dissimmilar to 
existing desktop apps. Weblogs, for example, are much more like a document 
with a little application than a typical VB app. In this case I'd argue 
that the HTML solution is superior in usability to something that would be 
produced with a typical toolkit. In this, and many other cases, there's 
really no need for all the additional sophistication (and complexity) of 
"XML-Soup" solutions.

> Demands for
> usability are rising but the complexity of HTML app development scales
> nonlinearly as even semi-usable experiences are sought.

A situation which WF2 will help by providing more common features 
integrated into UAs or javascript libraries. Developers will be able to 
create more sophisticated interfaces more quickly without needing to make 
the full leap to the XML-Soup stuff. Now I have no doubt that XML-Soup 
will provide better tools for some situations and I hope that in those 
situations it is used. But I doubt it will always be the right answer.

> It has to be possible to build rich apps,
> simply.

Indeed. But for many apps, using HTML (or HTML derived technologies such 
as WF2) as a basis is very much the simple solution.

> As someone else said in another thread somewhere "it's 2005 and
> we're still talking about rollovers". I happen to believe that "Street HTML"
> just won't cut it for building rich interactive clients that are highly
> usable (by the ultimately users, end users not developers), and that the
> best "worse is better" foundation lies in the XML technologies that have
> been established in recent years (XHTML among them), and that promoting
> these technologies would be better for the open/web community than letting
> proprietary tools win. Clearly a number of people on this list do not agree.
> We will see.

If the standardised XML solutions are to have any hope of being used in 
place of proprietry technologies, they have to be widely deployed and easy 
to develop for. As I've already said, that's simply not the case at the 
moment. Using HTML as a basis is attractive to developers because they can 
retain their existing assumptions about how one develops for the web and 
take advantage of universal HTML4 support. Using proprietry solutions is 
also attractive because these are likely to come with tools that make 
development easy. If the W3C wants to make XML solutions viable, they need 
to work on making them simple. As I said before, I think that lack of 
simplicity and the lack of a migration path away from HTML to more feature 
rich langauges will be a major detractor to the adoption of the 
technically superior XML solutions.