Re: Bug 7034

On 03/23/2010 03:41 PM, Leif Halvard Silli wrote:
> 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.

Yes.

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

The latter part of this paragraph is what I was intending to explore. 
The former part of this paragraph (specify a specific practice) is 
something I would like to suggest:

http://tinyurl.com/yagni

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

Yes.

>> 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? ;-)

No.

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

No.

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

No.  :-(

Obviously, I wasn't clear.

What I meant is that if I serve my content as application/xhtml+xml, 
then the namespace is required.  If I then pass that content to a 
validator, I need to buy into the ideology[1] that presentational 
elements need to be avoided.

I can live with that.

> 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

[1] http://lists.w3.org/Archives/Public/public-html/2009Feb/0127.html

- Sam Ruby

Received on Tuesday, 23 March 2010 19:58:53 UTC