[whatwg] Web Forms 2.0 - what does it extend , definition of same,

[Jim Ley]

On Tue, 11 Jan 2005 14:34:36 +0000, James Graham <jg307 at cam.ac.uk> wrote:
> Jim Ley wrote:
> >I'm looking for use cases
> >
> If a use case isn't a case where it would be used, and be beneficial,
> what is it?

> 1) A well debugged, easy to use, implementation. Better surely than a
> thousand slightly different, slightly broken implementations.

Except the declared policy is that the implementations will be done
using XBL and HTC's and a whole heap of javascript, neither of these
will be well debugged and easy to use for a very long time if ever. 
Are you creating them?  Is the WHAT-WG creating them?  In any case the
examples of HTML development is that developing browsers results in
lots of slightly different, slightly broken implementations, that you
end up using script to cope with.

> 2) A better UI. An <input type="date"> can provide me with a calendar.

You can do the same in script, indeed thousands of site already do this.

> 3) Better accessibility. A non visual client may be able to use the
> extra information about the type of information required to offer a
> better interface.

So we're straight back to the better accessibilty argument, and it's
possibly true at the tiny, tiny edge cases we're dealing with, it does
nothing for those who are genuinely marginalised by web-application
technologies, and certainly doesn't do anything to actually make
accessible a previously inaccessible page - given that fact I doubt
very much that any AT authors will be rushing to endorse the features
supported by a tiny minority of installed user agents.

Do you have some reason to believe AT's will actually take up Web
Forms, perhaps some AT authors posting to the list I've missed?

> Which is still quite possible in the new system. One would require
> javascript for this additional test to be performed client side but
> knowing that the email adress is syntatically correct before trying to
> test whether the TLD exists.

So we're straight away hitting javascript, avoiding which was the only
reason you've given to change to the declaritive method.

> If such a test is to be performed server
> side, one could use Web Apps 1.0's XmlHttpRequest 

This is not a Web Apps 1.0 feature, it's a partial implementation
Microsoft feature that has been available and used for years.   It
needs no standardisation, there's a MS reference implementation follow
it (which you'll have to do anyway since they're not going to change
to support Web Applications, and there's no way to do the rest of it
in script.)

> You haven't actually proposed anything that isn't
> already possible.

Neither has Web Forms 2.0 or Web Applications 1.0, indeed that's one
of my major points, don't wast the limited resources of your small
companies trying to hold the web back when the existing platform is
already sufficient for everything offered in the specifications.  Work
on things we can't do,  XBL and XUL in Safari and Opera would be a lot
more useful to web-application authors than this stuff.

Especially as without the IE implementation layer, it'll be completely
irrelevant, no-one will use it.

> But the question of whether that rich data is avaliable is totally
> orthogonal to the question of whether the Web App front end is written
> in HTML or not. There is no way to force someone with data to make it
> avaliable.

I'm not trying, I'm asking that the tools be made available (and they
are already in IE and Mozilla to a certain extent although not
standardised, and definately available with plugins) so that if they
want to make it available, and what to be able to create applications
easily they can.  At the moment we can't, because we're stuck
supporting excellent HTML user agents like Safari and Opera that are
intent on sticking to just HTML, holding everyone back.

The basic argument is that Web Forms fulfils no use cases that cannot
be achieved with script (given that in a backwards compatibility
requirement web-forms will have to be optional like script) so rather
than waste the limited development time of the browsers on this, they
focus on more useful areas to the web-application developer.

> If you
> are convinced that WHATWG work is of no use (or won't be used, which is
> the same thing), there is little point in your being here.

Of course there is, I could be wrong, in which case I want to make
sure I'm not suddenly shocked by what I see.

Jim.