Re: Bug 7034

On 03/23/2010 10:06 AM, David Singer wrote:
> Thinking out loud here...
> It does seem that we have a serious problem when the vast majority of
> sites fail to validate.  None of us like compiler warnings or errors;
> and we are certainly concerned that if a module 'normally' builds
> with scads of errors, we'll miss one that really ought to have
> attention paid to it.
> GCC has a whole pile of options for controlling what kinds of
> warnings you want to see (or rather, don't want to
> see).<>.
>  It's clear that some site authors do not care about some classes of
> potential problems: * they intend to use inline markup and not CSS *
> they do not care that XML serialization would be problematic * ...
> Should we classify the MUSTs and SHOULDs in the spec. into broad
> groups so that the validator can in turn classify the errors and
> warnings? "If this problem remains, your site will have problems with
> XXXX".

The following is a suggestion that I don't expect will not initially be 
popular, but I will put it out there in the spirit of brainstorming.  It 
truly is a "lets turn lemons into lemonade" suggestion.  I ask that 
everybody treat is as such.

There is a sincere desire by some people to require ampersands to be 
escaped, quote all attributes, close all open tags, get rid of tags such 
as acronym, and to rid the internet of the scourge that is 
presentational markup.

At the same time, the discussion about "this is XHTML" vs "not it is 
not" is showing no signs of going away.  This discussion even persists 
when the alleged XHTML is served as text/html, does not conform to any 
known schema or DTD, and even when is not well-formed.  I think that we 
have an opportunity to change the topic.

One possibility is to change the definition of the xmlns attribute on 
the html tag from being a talisman to an opt-in to best practices.

One downside of such an approach is that it would provide any means for 
people who author content intended to be served as application/xhtml+xml 
to opt out.

- Sam Ruby

Received on Tuesday, 23 March 2010 14:24:56 UTC