- From: David Hyatt <hyatt@apple.com>
- Date: Tue, 1 May 2007 13:49:31 -0700
- To: W3C List <public-html@w3.org>
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