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

On Tue, 11 Jan 2005 10:09:59 +0000, James Graham <jg307 at cam.ac.uk> wrote:
> Jim Ley wrote:
> >The web-forum and comment on data version of web-application is very
> >well addressed in existing HTML, could you provide exactly how the
> >WHAT-WG work is solving particular use cases in this scenario - yep,
> >I'm still asking for use cases months down the line, because I'm still
> >not hearing any.
> >
> Reread section 2 of the Web Forms spec for some of the more obvious
> improvements. 

I'm looking for use cases, I note you fail like everyone else to
actually deliver one.  The ability to restrict input client side to
your productions exists, there's no missing functionality on the web
today, certainly data entry in such systems already does it!

> The required attribute
> (section 2.7) provides a convenient mechanism for indicating that users
> cannot post without a valid email address (for example). Again, this
> will be possible without needing any client side javascript.

Yet, you've not explained the use case of not requiring client-side
javascript, quite apart from the fact all of this absolutely requires
javascript in all current user agents, and in effect all user agents
for the lifetime of most pages authored in the next 2 years.

At the same time, things like email are less rigourous validation than
is currently used (even if the email validation is almost always
incorrect syntactically) since they generally test that the TLD is a
valid one.

> Indeed. They could have used HTML 4's <link rel="alternate"> to point to
> the iCal data from the HTML page. Sadly, the convenience of building up
> HTML directly from the underlying database (not to mention the
> incompetence of Odeon) meant they didn't feel the need to insert an
> extra layer of abstraction between their db and the web page.

Exactly, which is why it makes sense to create web-application
language that can consume more complicated formats directly, then it's
not an extra page to provide and an extra level of abstraction, you
are simply rendering the semantic data.  It's a good use case, with
the current HTML crop we have to create n documents for each view
iCal, voice, HTML etc.  If web-application languages had things such
as XBL, we would be creating transformations from a single rich data
source.

> But that's a parallel problem to the problem of a sutiable language for
> creating a Web-based interface to the data (the actual topic at hand).

I understood the topic at hand is improving the robustness and ease of
authoring of web-applications?  Web-based interfaces do not mean HTML
even today

> Not at all. There are two questions here - can we make the front ends to
> web documents and applications accessible and can we make the underlying
> data avaliable for repurposing. 

This isn't true, the questions are very much linked, if you're
learning disabled and use a symbolic language like BLIS as your
interface to the world, no amount of HTML tweaking is going to make a
service accessible, a rich data format does make it possible.

The argument about WHAT WG work has focussed a lot on accessiblity
benefits, yet these are only tweaking the areas that are already
solved problems (the accessibility problems of current Web
Applications is mostly down to laziness)  Real accessibility benefits
for the harder to reach members aren't being addressed here.

> But making the base langauge extensible enough that it can be used for
> all possible situations also makes it unweildy, unoptimised and hard to
> use or understand.

I assume you're stating this as a fact having reviewed the currently
available solutions?  Some of which are being used by an awful lot of
developers using good frameworks that work well.  There's even W3c
standards on some of it.  Could you point me at some justification for
your statements?

Jim.

Received on Tuesday, 11 January 2005 03:34:40 UTC