Re: some technical thoughts about incremental improvements to forms

On Wed, 6 Sep 2006, Lachlan Hunt wrote:

> Dave Raggett wrote:
>> When people generate malformed markup they are putting themselves 
>> at the mercy of the browser's error handling behavior (Caveat 
>> scriptor)
>
> That is a major interoperability concern of browsers these days, 
> since incompatible DOMs can result a page that is built for, 
> tested, and relying on bugs in one particular browser to be 
> completely broken in another.
>
> IMHO, while it is meant to be the author's problem, authors that 
> fail to fix these problems make it the users' problem (when the 
> site doesn't work in their browser), which in turn makes it the 
> browser vendors' problem.

But even if one accepts that, it is still unrealistic to standardize 
such browser error handling, particularly given the lack of 
interoperability in existing implementations. The best I can suggest 
is to encourage people to check their markup, and to avoid authoring 
tools that are known to produce malformed markup. It isn't 
impossible to do so!

>>>>        <h:bind id="b1" name="fred"/>
>>> 
>>> It doesn't have to have been bound to a namespace for IE to 
>>> treat it as pseudo-XML
>> 
>> My tests showed that the prefix has to be bound to a namespace URI
>> for IE to allow CSS selectors to take effect on that element.

This is demonstrably true for IE6 and IE7 RC1. I am not sure what 
the relevance is of the DOM view you referenced.

>> I don't see why browsers should ignore the /> syntax as that only 
>> makes it harder to deploy mixed markup documents.
>
> Because that's XML syntax and HTML is not designed to contain 
> embedded XML. This is true whether you consider HTML to be an 
> application of SGML (where <x/> has a completely different 
> meaning) or the tag soup it really is today.

I agree that the complexities of the SGML specification have little
practical relevance to today's text/html browsers.

> It's already confusing enough for authors as to why they can use 
> <br />, but can't use <p /> and have it work as expected in 
> text/html.

That's an unfortunate historical accident. If XML had come before
HTML things would have been different, but that's too bad.

> Copying IEs approach of only recognising it for elements with 
> namespace prefixes is unacceptable because HTML has no concept of 
> namespaces and many people (particularly Hixie) consider 
> namespaces too complicated to use.

Maybe Hixie finds them too complicated, but namespaces are really 
quite easy to use in practice if you follow simple guidelines,
and much easier than many aspects of web page design.

> Besides that, there is no point introducing XML syntax into HTML. 
> As I said before, transitioning to XML through HTML is not the 
> right approach.  If such a transition is to occur, it absolutely, 
> positively, *must* (without a doubt) do so as *real XML* when 
> browsers sufficiently support the languages!

I appreciate your strong convictions on this point, but I feel
that the situation is rather more subtle than that.

Right now it is hard to deploy mixed markup widely on the Web
in any MIME type. We need to identify and gradually remove
the barriers to doing so. How would you go about making it
easier to use application/xhtml+xml as a case in point?

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

Received on Tuesday, 5 September 2006 17:50:49 UTC