[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.)
>
>
Possibly.
>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
>problems
>
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-whatwg.org
mailing list