W3C home > Mailing lists > Public > public-html@w3.org > April 2008

Re: several messages about New Vocabularies in text/html

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 04 Apr 2008 11:09:06 +0200
Message-ID: <47F5F032.1040303@gmx.de>
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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:54 UTC