W3C home > Mailing lists > Public > www-math@w3.org > October 2006

Re: MathML-in-HTML5

From: Bruce Miller <bruce.miller@nist.gov>
Date: Thu, 12 Oct 2006 11:17:57 -0400
Message-ID: <452E5CA5.7030205@nist.gov>
To: www-math@w3.org

David Carlisle wrote:
> It doesn't matter if they are prefied or not, just what namespace they
> are in.
> <m:math
>  xmlns:m="http://www.w3.org/1998/math/MathML"
>  xmlns="http://www.w3.org/1998/math/MathML"
>  xmlns:math="http://www.w3.org/1998/math/MathML">
>   <m:mn>1</m:mn>
>   <mo>+</mo>
>   <math:mi>a</math:mi>
> </m:math>

But David, you're _assuming_ XML rules for interpretting
namespaces! :>  Of course, you have to assume at least
some subset of XML rules for current IE to work.

Part of this discussion seems to be what, if any, namespace
rules will apply to HTML5.  If I've correctly followed
the discussion, there seems to be 3 alternatives:
 (1) XML Rules
     There seems to be some resistance to this.
 (2) Namespaces are meaningless/ignored in HTML5,
     but are necessary for IE's xml islands.
     There are two subcases:
     (a) <math xmlns="...">, with HTML5 ignoring the
       "xmlns" attribute.
     (b) MathML names are defined by HTML5 as "m:math", etc.
       (or whatever pseudo-prefix you like)
       <m:math xmlns:m="..."> 
       with HTML5 ignoring the "xmlns:m" attribute.
     In either case, "portable" HTML5+MathML would be
     invalid HTML5, having unknown attributes.
     And both would require MathML tools to generate
     only a very specific form of XML, hurting interoperability
    (3) Any other special interpretation seems to
     assume that an IE8 will come out soon and implement it.
     Moreover, if namespaces confuses authors now, just imagine!

>> So let's go with <mspan> (for pcdata, allowed only in <mtext>) for
>> text styling via CSS and <mlink> (attribute href, content pcdata,
>> allowed only in <mtext>) for "web page anchors" with text/html
>> compatibility.
> But is that really an improvement over the status quo for say mathml in
> docbook? If we are going to open up mtext (and I'm not sure we should at
> all) I still think I'd rather allow some (or all) of the "host language"
> elements into mtext so that the result is explictly contstrained to work
> in those environments. 

While I certainly sympathize with Bill on wanting to
have such nesting possibilities, I'm not fond of adding
in little bits here & there.  I'd much rather push for
a proper solution at the level of compound documents.

Received on Thursday, 12 October 2006 15:32:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:42:12 UTC