Re: Bug 7034

Sam Ruby, Tue, 23 Mar 2010 10:24:15 -0400:
> 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).<http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Warning-Options.html#Warning-Options>.
>> 
>>  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.

So, I guess you talk specifically about 
xmlns="http://www.w3.org/1999/xhtml", and not other namespaces.  
And thus that you refer to some XML/XHTML based best practise.  

But if I want to specify a specific practise. The version attribute? 
(e.g. version="XHTML+RDFa 1.0") And @profile? Additional namespace 
declarations? A particular doctype? This is *pretty much* what we 
have today. The xmlns in the <html> start tag does represent a best 
practise signal today. However, we could define what kind of best
practise it represents, better. Should any of the other practise 
indicators (profile, version etc) depend on the presence of <html 
xmlns="http://www.w3.org/1999/xhtml">? As an example: If I use <html 
xmlns="http://www.w3.org/1999/xhtml">, then it could be expected that I 
use XML compatible numeric character references. Whereas if I don't use 
the xmlns attribute, then it would even be permitted with NCR without 
the closing semicolon [bug 9300]. I could personally live with that.

And did you also mean that the presence of 
xmlns="http://www.w3.org/1999/xhtml", does not per se change the 
behavior of the user agent? But rather changes the behaviour of the 
author, so to speak?

> 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.

Did you mean "opt out of text/html and serve as application/xhtml+xml 
instead" = text/html looses a customer? ;-)

Or did mean the opposite "opt out of application/xhtml+xml and serve as 
text/html" = application/html+xml looses a customer?

Or did you have in mind a text/html author who wants to break the best 
practises that the xmlns implies, could simply opt out of the 
requirements, by removing the xmlns = text/html best practise looses a 
customer.

It seems to me that it is only the last option that can in any way be 
called a downside ... There are some best practises that are not 
related to whether I close each <p> element, for instance. The good 
side is that, even when I remove the xmlns (I could simply change it to 
a class attribute ...), the "extra stuff" that I placed inside the 
document because I - for a while - used the xmlns attribute during the 
authoring process, will still remain legal HTML (if we do it right.) 
For the most part, the only illegal thing in documents without the 
xmlns, would then be the xmlns itself, I gather. Would there not be 
*any* "best practise" expected when not using xmlns? What about HTML4 
doctypes?

On the whole, I border on finding this approach very good.

[bug 9300] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9300
-- 
leif halvard silli

Received on Tuesday, 23 March 2010 19:42:29 UTC