jkd
11-10-2005, 03:53 AM
A recent project I've undertaken requires these three XML applications working seemlessly together. Mozilla is the only browser which natively supports SVG, MathML, and XHTML; however some recent hackery lets us to fudge this.
First step, Opera. Opera began supporting SVG recently, and its XML support is top knotch. So while it doesn't know how to render MathML, we can still style it with CSS and the like. MathML in CSS stylesheets have been written before, so this workaround is somewhat usable, for at least limited subsets of MathML 2.0.
Lastly, Internet Explorer. This was the interesting one - no real understanding of how to render XML. My first step was MathML - turns out the MathML plugin, MathPlayer, silently intercepts requests for XML documents in IE, and if it discovers a MathML+XHTML doctype, will internally convert the page into HTML with whatever IE hackery included. *Excellent*, as now we can also use the binary behaviors hack for Adobe SVG Plugin to let us do inlined SVG like one would do VML.
A demo page:
http://www.jasonkarldavis.com/inlinexml/
Caveats (in order of importance):
1. We cannot use the XHTML+MathML+SVG doctype that the W3C kindly provides for us. MathViewer is only triggered by it seems a particular doctype, and it's silent converstion to HTML is what makes this entire thing work. So we're actually left with invalid XML, but browsers which would care (Mozilla and Opera) are non-validating. Ideally MathViewer could be triggered by any doctype containing the text "MathML"... I intend to email them with this request sooner than later.
2. IE does not style the MathML or SVG through CSS. Either we use presentation attributes or I write a big css parser/applier/kludge. The latter will come soon if no other solutions can be found.
3. We cannot include the SVG directly into the <annotation-xml/> element. MathViewer hides whatever it doesn't understand, including the SVG. As a workaround, I've just xref'ed the annotation-xml element to an external SVG element. If you wanted to be a perfectionist, one could grab the SVG element from the DOM and move it outside the math element and dynamically xref it in some IE-only code.
4. We *must* namespace the SVG element. Not such a big deal, but aesthetically annoying if you have a lot of SVG elements. Once again, required only for IE.
4 significant hacks required for IE, but it works. Really exciting! Anyway, this is all part of some dynamic SVG graph generation from parsing MathML equations and stuff that I'm working on, but I figured the triple XML application document working cross-browser would garner some interest.
First step, Opera. Opera began supporting SVG recently, and its XML support is top knotch. So while it doesn't know how to render MathML, we can still style it with CSS and the like. MathML in CSS stylesheets have been written before, so this workaround is somewhat usable, for at least limited subsets of MathML 2.0.
Lastly, Internet Explorer. This was the interesting one - no real understanding of how to render XML. My first step was MathML - turns out the MathML plugin, MathPlayer, silently intercepts requests for XML documents in IE, and if it discovers a MathML+XHTML doctype, will internally convert the page into HTML with whatever IE hackery included. *Excellent*, as now we can also use the binary behaviors hack for Adobe SVG Plugin to let us do inlined SVG like one would do VML.
A demo page:
http://www.jasonkarldavis.com/inlinexml/
Caveats (in order of importance):
1. We cannot use the XHTML+MathML+SVG doctype that the W3C kindly provides for us. MathViewer is only triggered by it seems a particular doctype, and it's silent converstion to HTML is what makes this entire thing work. So we're actually left with invalid XML, but browsers which would care (Mozilla and Opera) are non-validating. Ideally MathViewer could be triggered by any doctype containing the text "MathML"... I intend to email them with this request sooner than later.
2. IE does not style the MathML or SVG through CSS. Either we use presentation attributes or I write a big css parser/applier/kludge. The latter will come soon if no other solutions can be found.
3. We cannot include the SVG directly into the <annotation-xml/> element. MathViewer hides whatever it doesn't understand, including the SVG. As a workaround, I've just xref'ed the annotation-xml element to an external SVG element. If you wanted to be a perfectionist, one could grab the SVG element from the DOM and move it outside the math element and dynamically xref it in some IE-only code.
4. We *must* namespace the SVG element. Not such a big deal, but aesthetically annoying if you have a lot of SVG elements. Once again, required only for IE.
4 significant hacks required for IE, but it works. Really exciting! Anyway, this is all part of some dynamic SVG graph generation from parsing MathML equations and stuff that I'm working on, but I figured the triple XML application document working cross-browser would garner some interest.