[whatwg] Web Forms 2.0 - what does it extend , definition of same,relation to XForms, implementation reqs.
jg307 at hermes.cam.ac.uk
Sun Jan 9 09:29:36 PST 2005
On Sat, 8 Jan 2005, Bill McCoy wrote:
> 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
> 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
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,
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.
More information about the whatwg