W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2005

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

From: Jim Ley <jim.ley@gmail.com>
Date: Tue, 4 Jan 2005 17:39:20 +0000
Message-ID: <851c8d31050104093952778b14@mail.gmail.com>
On Tue, 04 Jan 2005 16:54:37 +0000, James Graham <jg307 at cam.ac.uk> wrote:
> Sorry, I meant that Google don't use appropriate semantics in their own
> HTML documents, not that they don't use semantics when calculating
> search relevance of other HTML documents. View - Source on the results
> of a Google query indicates a bunch of <font> tags, tables and various
> other things but no heading elements, for example.

A Heading element is the only thing missing from googles front page,
they're using LABEL for etc. on their forms.  HTML simply doesn't have
enough semantics to do more.  People seem to me very confused about
semantic mark-up here, HTML has virtually no semantic mark-up, it has
the semantics for web-documents, nothing else.  For the data layer of
web-applications, web-documents are irrelevant, we're transfering
other semantics (accounts data in salesforce, email data in GMail,
photo data in flickr etc.)

So when we're talking about semantics in the data layer, HTML
semantics are not going to cut it.

> > the point is that
> >incremental edge additions to HTML won't achieve anything
> >
> Achieve in what sense? It certianly has the possibility of making many
> existing documents "more semantic" than they were before (by enabling
> new functionality without author-JS) and offering a better user
> experience for ordinary people. That seems to be achieving something.

I don't agree, there's nothing in Web Forms, even Web Applications 2.0
that changes GMail, it's here today, it may make it easier to do some
of it, but not a great deal so and that advantage will be irrelevant
due to the huge legacy environments.  Web Forms, like any technology
will take a long time to get popular, the browsers need to get
authored, the authors need to educated, the bugs need to be worked out
etc.

It seems to me that so many of the people here are thinking in the
1998 mindset when the growth was such that new browsers quickly
swamped old browsers so you could keep introducing these tiny
improvements.  We're not, we've got a stable environment that we all,
and all our toolsets know how to work with, developing web documents
costs a fraction of what it did 3 years ago, not because of great
standards support, but because the dominant browser hasn't changed in
all that time.  Web forms are very unlikely to suddenly make IE
change, and without that, there is no reason to increase your costs,
buy new tools and re-learn all the techniques to change nothing about
what the end user sees.

The argument that it's slightly more semantic is true, but you've just
made a good case for why authors are not interested in more semantic.
> >you have to believe that it'll offer significant advantage 
> >I can see none
> I can :)

So what is it?  What's the significant advantage - will it reduce my
development costs?  Will it improve my users experience? or  ....

> I thought the new consensus was that implementations before spefications
> had reached a stable Call For Implementations phase were a bad thing anyway?

Of course it's a bad thing, but that doesn't change the fact it's not
implemented, and that real commercial viability of the features is a
very long way in the future, and the more Safari, Opera and Mozilla
penetrate the market in the mean-time, the less the use case to using
it will be, since as well as the legacy aspect of IE to consider,
there's the legacy aspect of all these installed users.

> They don't suffer from the same fundamental problems. Webforms allows
> you to extend existing documents. In simple cases this will be
> effortlessly backward compatible.

but in those simple cases, the vast majority of your users get a crap
user experience.

> XForms requires that you ditch everything you know, learn a
> bunch of complex specs, find a CMS that will deal with XML in a sane way
> and then start again with all your content. It precludes any possibility
> of backwards compatibility. These are hardly the equivalent situations
> you make out.

However, you're selling webforms over XForms, you've not yet sold the
case for WebForms over HTML4 forms.  I'm no XForms fan, I have less
belief in what the HTML WG are doing than this organisation, but at
least they've realised playing at HTML ages isn't really too
profitable.

> > - You can create compatible WebForms docs within the single
> >document, but it's far from trivial, and you miss out on quite a few
> >of the benefits.
> >
> So there are benefits to WebForms after all?

There's benefits to all sorts of things, they need to outweigh the
cost though to be used.  If I thought there was no value in Web Forms
at all, I wouldn't be wasting my time here, there's some value, and
there could be a miracle that meant it succeeded, I very much doubt
it, but if it did, then I need to ensure that it meets my needs as
much as I possibly can.

At the moment WebForms offers very little, for average cost.  XForms
combined with other XML workflows offers a lot for an absolutely huge
cost.  Neither are providing a reason to move.   Web Forms has always
felt like a defensive measure from HTML browser vendors so as not to
do work on creating a real next generation user agent, and decrease
the reasons to switch to other richer UAs.  Formsplayer that combines
SVG, XBL,  XForms and IE HTML browsing is a much more persuasive sale
of what a next generation user agent might look like.  Yes the cost of
moving to it is large, but it offers reasons to change, I've yet to
find a reason to change to Web Forms 2.

Jim.
Received on Tuesday, 4 January 2005 09:39:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:20 UTC