[whatwg] Web Forms 2.0 - what does it extend , definition of same,
jg307 at cam.ac.uk
Tue Jan 11 06:34:36 PST 2005
Jim Ley wrote:
>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
>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?
>, 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!
Indeed. But doing it client side via declarative markup rther than
scripting has several advantages:
1) A well debugged, easy to use, implementation. Better surely than a
thousand slightly different, slightly broken implementations.
2) A better UI. An <input type="date"> can provide me with a calendar.
An <input type="email"> can prefill my email address or offer my system
3) Better accessibility. A non visual client may be able to use the
extra information about the type of information required to offer a
>>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
>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
Which is still quite possible in the new system. One would require
knowing that the email adress is syntatically correct before trying to
test whether the TLD exists. If such a test is to be performed server
side, one could use Web Apps 1.0's XmlHttpRequest to provide the
required communication so that the page could offer a seamless user
experience, with no need to load seperate error pages after every
mistake (so damaging history, caches, etc.)
>>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.
I don't understand at all how that would work. Given that the back end
will always be a database, and that the front end will always need
elements other than the semantic data (prose, buttons, etc.) what you're
saying doesn't make sense. There will always be a seperation between the
data and the front end and making the data avaliable in some
data-specific semantic format at the front end will always be harder
than just presenting a display of the 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
Eh? This makes no sense. If I have a data source I can already present
as many views of the data as I want (by "transforming my rich data
source") and make each view avaliable to clients that understand it. As
far as I can tell, you haven't actually proposed anything that isn't
already possible. If you have in fact proposed something new, can we
have details of how it would work please? You've also carefully snipped
all the reasons that, even though underlying data can already be made
avaliable to clients, few web apps choose to do so i.e. the reason that
any technology like the one you describe would be ignored in many
>>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?
Indeed. So why are you talking about technological pipe dreams that,
even if realised, would be ignored by many users (because it would be
contrary to their goals as a business, for example)?
>>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.
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. It is, however, possible to make the front end to the data
usable by a many (perhaps not all but certianly a large number) of
people. That's the focus because it's the only realistic goal.
> Real accessibility benefits
>for the harder to reach members aren't being addressed here.
You have oppertunity to comment on accessibility issues in the mailing
list. However instead we seem to having all this meta-discussion. 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. If you are
convinced it is of some use but not perfect then you are quite correct.
One simply can't solve all possible problems when a design requirment is
backwards compatibility. If you don't think backwards compatibility is a
necessary design requirment, there is little point in your being here
because it is undoubtedly much easier to create a cool technology that
solves a bunch of problems with a clean sheet of paper.
>>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
Technologies such as RDF/XML are prime examples of standardised,
extensible and unwieldy formats that are hard to use and understand.
Sure, that's a metaformat rather than an actual way of communicting
specific data but it is exactly those properties that lead to it being
bypassed by real data communicating formats such as Atom and lead to
existing RDF-based solutions such as FOAF gaining competition from much
simpler, easilly implemented formats such as XFN. It is also true that
just about every format that is widely used and standardised is abused
in some way - HTML (when used for simple documents) is an obvious
example, as is RSS.
More information about the whatwg