W3C home > Mailing lists > Public > public-html@w3.org > May 2010

Re: ISSUE-4 - versioning/DOCTYPEs

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 18 May 2010 03:19:20 +0200
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: Sam Ruby <rubys@intertwingly.net>, public-html@w3.org, Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Message-ID: <20100518031920051747.8ef133f0@xn--mlform-iua.no>
Boris Zbarsky, Mon, 17 May 2010 13:54:28 -0400:
> On 5/17/10 1:52 PM, Sam Ruby wrote:
>> If there is to be a switch of some kind, I
>> would suggest that it be based on something that is likely to make an
>> operational difference, and that's why I prefer keying off of the
>> presence of the xmlns attribute on the html element.
> 
> That would make sense to me too.  Good idea!

I do not want to rule this out. But are there anyone using this as a 
switch today?

Would you expect e.g. KompoZer or BlueGriffon to produce XHTML polyglot 
syntax if the document contains an xmlns attribute, is that what you 
say? What does editor developers, such as Daniel, think of this? Isn't 
this far to subtle?

How "correct" must the xmlns be before it will be taken a such a 
"flavor trigger"? 

Aren't there some advantages to using a DOCTYPE: the editor/tool can 
insert the xmlns, one behalf of the author, if it is lacking. For 
instance, the document could be a perfectly valid HTML5 document, with 
inline SVG and MathML, but sans any xmlns. If on placed there a XHTML 
polyglot doctype, then the tool/editor could auto insert the xmlns-es 
for me. Can a single xmlns inside the <hmtl> have the same function? I 
think that may become too accidental?

Don't DOCTYPEs *make* an operational difference: They trigger 
strict/quirks/almost-strict mode in text/html?

Note, again, that HTML5 says that it doesn't make any rules for 
DOCTYPEs on the XML side. However, I think we could make some rules for 
doctypes inside text/html: they must not trigger anything else but 
non-quirks.
-- 
leif halvard silli
Received on Tuesday, 18 May 2010 01:20:29 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:02 UTC