Re: Support Existing Content

Other people touched on these points, but I think they bear repeating:

(1) XHTML is the draconian path.  Making HTML5 also be draconian (and  
a compatibility break like XHTML) is simply not necessary when  
authors who desire such a draconian model can simply use XHTML  
instead.  The whole point of not making a compatibility break is so  
that authors can keep using the same syntax and language as before.   
Once you've decided to make a compatibility break you might as well  
switch to XHTML only.

(2) Asking HTML to have better-defined rules for handling invalid  
content is asking HTML to be *more* like other W3C specifications not  
less.  Nobody is trying to state that such documents are valid or  
conforming.  What we are trying to state is that a specification  
should define as much as possible how invalid content should be dealt  
with, in the same way that a documented API (DOM anyone?) should  
define what happens when it is passed illegal values.

Too many people seem to be jumping to the conclusion that adding  
better-defined error handling somehow implies that we would consider  
these malformed documents to be valid.  Of course they aren't.  We  
don't consider broken CSS documents to be valid either.  However,  
having rules that specify precisely how error recovery should occur  
enable implementors to achieve interoperability when invalid HTML is  
(inevitably) thrown at their browsers.

A spec can talk about error cases, or it can talk about deprecated or  
poorly designed attributes, without taking away from the "purity" of  
the language.  As long as these sections are clearly delineated and  
make it clear that error cases or deprecated elements are being  
discussed, where is the harm?

dave
(hyatt@apple.com)

Received on Tuesday, 1 May 2007 20:50:26 UTC