- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 04 Apr 2008 11:09:06 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: Sam Ruby <rubys@us.ibm.com>, Jeff Schiller <codedread@gmail.com>, Henri Sivonen <hsivonen@iki.fi>, HTML WG <public-html@w3.org>, Public MathML mailing list <www-math@w3.org>
Ian Hickson wrote: > Indeed, and we already have name clashes (one, for MathML; at least half > a dozen, for SVG). > > This isn't the design I would have picked if I was designing this in a > vacuum. However, we have to deal with the existing content. This has been > an underlying theme for the HTML5 effort since we started in 2004. > (Actually, since even earlier, with the Web Forms 2 work going back to > late 2003.) > > If we're willing to consider solutions that _don't_ take the existing > legacy content into account, we're better off doing a more thorough job > and going with something like XHTML2, XML, XML Namespaces, and so forth. There's a gray area between "all" existing content and "most" existing content. If "all" content needs to be considered, we essentially can't do anything new. >> HTML has also allowed adding new element names > > HTML has never allowed custom element names. *Browsers* do allow custom element names. I may be wrong WRT the spec; will have to research. >> Anyway, if "xmlns" really can't be used, there's nothing stopping us >> minting a new attribute name that has the same effect. > > I did consider that, but it still fails in the face of early adopter cargo > cult behaviour, and loses compatibility with XML, which is one of the main You keep repeating that :-) I don't buy it. > reasons to try this in the first place. I mean, if we aren't going to get > syntax compatibility with XML, the details of the syntax become somewhat In which case I'd argue to try harder to achieve syntax compatibility with XML, at least with a subset (no DTD, ...). > secondary, and you might as well turn > > <foo ns="bar" baz="quux"> > > ...into: > > <span class="bar-foo" data-baz="quux"> > > ...since the difference is purely syntactic at that point. Right. But I thought that syntax *does* matter to most of us. >> Out of curiosity: where does the requirement to include HTML (not XHTML) >> into MathML come from? > > I don't have a note of the precise e-mail that listed the problem being > solved here, but it should be in this list somewhere: > > http://www.whatwg.org/issues/#html-parsing-rules-namespaces-discussion > > If you mean why don't we simply use XHTML, that's a language design > decision. We already have a language that can combine MathML and XHTML, > it's XML. There's no point solving the problem twice the same way. It Let me rephrase that to "There's no point in solving this problem *again*". > would also be extremely confusing to most regular authors if HTML elements > behaved one way in certain parts of their documents and another way a few > lines lower down. For example, it would make copy-and-paste within a > single document fail to work faithfully, which is far worse than > copy-and-paste across documents of different MIME types not working. On the other hand, you would introduce a new syntax that is incompatible with deployed MathML. That's IMHO even worse. BR, Julian
Received on Friday, 4 April 2008 09:09:59 UTC