Atoms for Content MathML
Henri Sivonen
https://developer.mozilla.org/en/Mozilla_MathML_Project/Status
Yet, we've carried around atoms for Content MathML since 1999:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/mathml/content/src/nsMathMLAtomList.h&rev=1.1&root=/cvsroot
1) Do we want preserve Content MathML upon paste into Gecko when the paste is subjected to the sanitizer?
2) If not, do we want to keep the Content MathML atoms around?
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Jonas Sicking
> If I've understood correctly, Gecko doesn't currently support Content MathML and it is not even planned:
> https://developer.mozilla.org/en/Mozilla_MathML_Project/Status
>
> Yet, we've carried around atoms for Content MathML since 1999:
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/mathml/content/src/nsMathMLAtomList.h&rev=1.1&root=/cvsroot
>
> 1) Do we want preserve Content MathML upon paste into Gecko when the paste is subjected to the sanitizer?
As with any feature, I don't think we should do it unless people are
asking for it. And even then look at the requests with a critical eye
and ask for use cases.
So in short, I'd say if it's extra work, lets not do it unless someone
can give good reasons to.
> 2) If not, do we want to keep the Content MathML atoms around?
Not if they're not used elsewhere.
/ Jonas
Henri Sivonen
> On 1/28/2011 6:09, Henri Sivonen wrote:
>> If I've understood correctly, Gecko doesn't currently support Content MathML and it is not even planned:
>> https://developer.mozilla.org/en/Mozilla_MathML_Project/Status
>>
>> Yet, we've carried around atoms for Content MathML since 1999:
>> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/mathml/content/src/nsMathMLAtomList.h&rev=1.1&root=/cvsroot
>>
>> 1) Do we want preserve Content MathML upon paste into Gecko when the paste is subjected to the sanitizer?
>
> As with any feature, I don't think we should do it unless people are asking for it. And even then look at the requests with a critical eye and ask for use cases.
>
> So in short, I'd say if it's extra work, lets not do it unless someone can give good reasons to.
This isn't about the amount of work. If we don't whitelist Content MathML, it takes work to see which atoms I can remove and to remove them. I we do whitelist Content MathML, it takes some work to review that the list is right.
I think this more a question of footprint and a question the consequences of allowing or corrupting Content MathML upon paste. It's also a question of being able to copy Content MathML from feed content. (In theory, there's also the question of math accessibility, but lets cross that bridge once accessibility has caught up with Presentation MathML first, which is much more important to catch up with.)
If we assume Gecko won't implement Content MathML rendering any time soon, there are two cases why one could care about having it in the DOM:
1) Allowing authors to provide XBL2 bindings for rendering a Content MathML into a Presentation MathML shadow tree. (But once someone does this in a reasonably complete way, I think it would make more sense to bundle that XBL2 binding with Gecko.)
2) Round-tripping math expressions from symbolic math software onto the Web and back.
The scenario is that a symbolic math program, such as Mathematica or Maple, would export Presentation MathML with and embedded alternative Content MathML subtree that encodes the "same" thing as the Presentation MathML part. Firefox and other browsers would render the Presentation MathML but when copying and pasting the whole <math> subtree around, the Content MathML part would invisibly travel along. When pasted back into a symbolic math program, that program would throw away the Presentation MathML part and use the Content MathML part instead.
On one hand, letting Content MathML travel along would be at least in theory nice for symbolic math programs. On the other hand, the above scenario can be recognized as the "invisible metadata" antipattern. If Gecko allows pasting Presentation MathML with Content MathML subtrees, should we also add code that zaps the Content MathML alternative representation if the user edits the Presentation MathML at all in contenteditable? Is it wrong to let the user copy and paste around data that the user doesn't know (s)he is copying and pasting? (Well, there are already many other ways of smuggling data in copy and paste without the user's knowledge of what's being transfered.)
One consideration is that circa 2000, Mathematica tried to enable round-tripping in its image-based export by putting proprietary Mathematica language in the alt attribute of images in order to make copy from a browser and paste back into Mathematica work. If we zap Content MathML, there's a risk that software that really, really wants to round trip symbolic math semantics tries to smuggle the data in less elegant ways than using Content MathML. OTOH, if we whitelist Content MathML now, chances are that we'll never get rid of the atom footprint. One one hand, the atom footprint is a drop in a bucket. On the other, small streams make a big river.
(FWIW, the code I have right now corrupts SVG fonts upon paste, because we don't have the atoms for that stuff, and SVG fonts have been put in the "bad for the platform" department.)
CCing dev-tech-mathml where I probably should have started this thread in the first place.
Ehsan Akhgari
> If I've understood correctly, Gecko doesn't currently support Content MathML and it is not even planned:
> https://developer.mozilla.org/en/Mozilla_MathML_Project/Status
>
> Yet, we've carried around atoms for Content MathML since 1999:
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/mathml/content/src/nsMathMLAtomList.h&rev=1.1&root=/cvsroot
>
> 1) Do we want preserve Content MathML upon paste into Gecko when the paste is subjected to the sanitizer?
I think we do want to preserve Content MathML upon paste/drop.
Ehsan