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

James Graham jg307 at cam.ac.uk
Tue Jan 4 08:54:37 PST 2005

Jim Ley wrote:

>On Tue, 04 Jan 2005 15:29:16 +0000, James Graham <jg307 at cam.ac.uk> wrote:
>>It's not only an extreme example, it's a terrible example. Google have
>>repeatedly shown that they have no interest in using the semantics
>>available in HTML,
>That's because there is no semantics in HTML other than web document
>semantics, something it is actually highly likely it uses - since most
>other search engines do.  Hn elements more important, google lists
>reading from OL/UL etc.
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.

>>Even allowing that your example is misguided, I'm not sure I believe the
>>rest of the argument either. In order to believe that HTML should be
>>starved in order that XForms should flourish,
>It's not a case of starving one to boosting another
That seemed to be Bill's point. It's certianly the position that the 
HTML WG has taken.

> 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.

>>you have to take the
>>position that there will be a migration to XForms (and XHTML) from HTML.
>>In order to believe that this will offer a significant advantage to the
>>semantics of the web, you have to believe that authors will tend to use
>>the new features offered by XForms in the way that they are designed to
>>be used. In practice, I'm thoroughly unconvinced of the first and
>>skeptical of the second.
>However you have the same problems with the migration to WebForms and
>WebApplications from HTML, you have to believe that it'll offer
>significant advantage (

>I can see none
I can :)

>it simply doesn't work on
>any user agents yet,
Well that's kind of true although parts of it are implemented in Safari. 
I thought the new consensus was that implementations before spefications 
had reached a stable Call For Implementations phase were a bad thing anyway?

> and there's no likelyhood of it happening on IE -
>especially if binary plugins are rejected as a solution.)

>You can't claim the migration to XForms won't happen, but somehow the
>migration to WebForms will, they both suffer from the same fundamental
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. In more complex cases care will be 
needed. 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.

> - 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?

>  I don't in fact believe it will be easy enough for
>your normal developer, just like XForms isn't - It took Ian a few
>attempts to create the few basic examples on the site, and he's hardly
>your average developer.
I don't understand what you're proposing then. Web Forms is more or less 
the simplest thing it could be - it extends existing widely used 
technology in a spirit in keeping with the original. Are there specific 
ways to make it easier for developers to learn?

More information about the whatwg mailing list