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