Shane McCarron wrote:
> There has been some debate about this. In the current (not yet
> uploaded) draft this is not prohibited.
yay! :)
> I think that there is value in telling people about use that would
> potentially cause portability issues. It is not clear to me how to do
> this in a way that does not give more weight to these guidelines than
> they deserve though. The Guidelines are just that. You do not need
> to follow them. In theory, only people who are writing XHTML that is
> to be delivered as text/html to legacy user agents need worry about
> these. In reality, that is everyone who is writing XHTML for web,
> since the web has IE, and IE doesn't support XHTML.
Maybe IE9 will be the browser that makes real XHTML on the WWW practical.
> It's not that we don't appreciate the problem - we do. We just don't
> know how to give some people good advice without giving others bad
> advice - in particular when we don't know what problem they are trying
> to solve. Perhaps if the validator had an /option/ that turned on/off
> this mode, then the user could decide what they cared about?
I would expect any HTML compatibility testing alerts to be issued as
warnings (not errors), and only if the document was served as text/html
(perhaps with a "This document did not pass HTML compatibility testing,
which might be an issue if you serve it as text/html. You may wish to
<a>see the results of HTML compatibility testing</a>." for
application/xhtml+xml documents).
>> OK, got confused by â€œW3C Note 26 November 2008â€