- From: Geoffrey Sneddon <foolistbar@googlemail.com>
- Date: Mon, 19 May 2008 17:57:42 +0100
- To: Anne van Kesteren <annevk@opera.com>
- Cc: HTML Working Group <public-html@w3.org>
On 3 Apr 2008, at 18:06, Geoffrey Sneddon wrote: > > On 3 Apr 2008, at 17:06, Doug Schepers wrote: >> Henri Sivonen wrote (on 4/3/08 11:03 AM): >>> Once you allow this, the whole <ext> element becomes pointless. >> ... >>> That violates one of our design principles: >>> http://www.w3.org/TR/html-design-principles/#dom-consistency >>> And not even for a good reason once you allow the omission of the >>> <ext> tag in source. >> >> Like I said, I'm not advocating it, and I don't even like the >> idea. I was just playing around with details. I'm quite happy to >> reject this idea, but the question remains as to what to do when >> such content is encountered. Perhaps we allow both scenarios... >> I'm convinced that <ext> is better, though. > > To get around that problem, could we just not put <ext> in the DOM, > and effectively lose it at a parser stage? <ext> definitely seems > one of the better solutions mentioned. Anne asked me to give reasons why I thought this was the best solution a while ago (on April 3rd itself, actually), so to finally answer his question: Having an element as a wrapper would allow namespaces except for those explicitly allowed (currently only MathML) to be included. It need not violate one of our design principles, DOM Consistency, as it could be purely a parser level element, and never ever reach the DOM (this could be confusing though). The more I try and argue this position, the more I think it isn't actually a particularly good argument: in many ways using the hyphen as a namespace separator would work. Is there a large body of content that all ready relies on the hyphen being a generic character? To get around that issue, we could simply only give it special treatment if there is already a declared namespace with that prefix (is that not how Namespaces for XML deals with foo:bar, which is just literally that per XML? I don't have internet access right now so I can't check). This would give us DOM Consistency, and though it would mean the serialisations for foreign content between HTML and XHTML are different, but it wouldn't reduce the already small subset of HTML that is XHTML. Is there any content that relies on an "xmlns" attribute having no meaning in HTML (paying attention to it on the root element when it is equal to "http://w3.org/1999/xhtml" doesn't break anything anyway)? Those with colons would still have no further meaning. If there is, then perhaps <ext> would be a better solution… -- Geoffrey Sneddon <http://gsnedders.com/>
Received on Tuesday, 20 May 2008 18:56:49 UTC