Re: MathML-in-HTML5

> For application/xhtml+xml my impression is that Mozilla does _not_
> recognize, for example, unprefixed MathML leaf elements inside an
> <m:math>, while it does recognize them inside <math xmlns=...>.

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>

etc is fine.If you use unprefixed elements inside m:math without
declaring the default namespace to be mathml then that's an error, the
elements will be either in no namespace or in the xhtml namespace
(depending what's outside the math)

> Might one not have user agent internal security concerns about this
> unless validation by user agents is mandated? 

Any plugin architecture (or any browser) or any software at all, really,
has some security implications. I don't see that the issues here are any
different than any other web page browsing. If I install firefox (for
example) on my machine then basically I need to trust that it, itself, is
not malicious. the fact that it can execute mathml-in-svg-in-xhtml
doesn't really pose any extra security issues. The fact that these are
specified as a compound document format is just really a specification
issue. If the browser (as in IE) is using external components to render
teh various fragments, then its true you do need to trust each
component. But these are rendering engines, it's not like running
arbitrary executable code embedded in a random web page.

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

an mtext containing an xhtml <a href="..." is explictly a mathml+xhtml
construct and only usable in mathml+xhtml systems.

If you add mlink to mtext, or css-styled mspan  then you have to specify
what that means in docbook, or maple etc where there is no css, and the
linking models are rather different.


David

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