- From: Sam Ruby <rubys@intertwingly.net>
- Date: Tue, 23 Mar 2010 15:58:10 -0400
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- CC: David Singer <singer@apple.com>, Henri Sivonen <hsivonen@iki.fi>, Maciej Stachowiak <mjs@apple.com>, Philip Taylor <pjt47@cam.ac.uk>, HTMLwg WG <public-html@w3.org>
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