Four points here. 1. We're assuming that MathJax is as good with MathML as it is without it, but perhaps we could ask the MathJax folks to comment on whether this is true. I'd certainly be a lot more comfortable dropping MathML if the MathJax folks said there was no point.
2. > A suitable subset of TeX (not > the entirety of TeX, as that is a huge, single-implementation technology > that reputedly only Knuth ever fully understood) was the right choice all > along Jonathan Kew is a much better person to comment on this, but in my relatively limited experience typesetting documents in TeX, I've had to use various LaTeX packages (particularly amsmath and amssymb) in order to get all of the symbols and so on that I needed. I suspect that "heavy" users of TeX frequently need more than these two packages. The point being, "a subset of TeX" isn't necessarily sufficient. 3. It's not clear to me why we should go through all the work of rewriting MathML into this TeX thing unless we thought that the new thing would see more enthusiastic adoption. It sounds like you would probably agree on this point. 4. > 2.2. High-quality mathematical typography in browsers is now possible, > without using MathML. Examples include MathJax ( http://www.mathjax.org/ ), > which happily takes either TeX or MathML input and renders it without > specific browser support, and of course PDF.js which is theoretically able > to render all PDFs including those generated by pdftex. Both approaches > give far higher quality output than what any current MathML browser > implementation offers. Could you elaborate on how MathML is inferior to MathJax's HTML+CSS rendering? MathJax has a page where you can switch between different rendering modes, and to my eyes, the two modes are almost identical. The only difference I see is that the HTML+CSS mode is better at correctly sizing large parentheses and radicals, but I wouldn't call this "far higher quality." http://www.mathjax.org/demos/mathml-samples/ On Sun, May 5, 2013 at 11:38 AM, Benoit Jacob <jacob.benoi...@gmail.com> wrote: > Hi, > > Summary: MathML is a vestigial remnant of the XML-everything era, and we > should drop it. > > *** > > 1. Reasons why I believe that MathML never was a good idea. Summary: > over-specialized and uniformly inferior to the pre-existing, > well-established standard, TeX. > > 1.1. MathML is too specialized: we should be reluctant to have a > separate spec for every kind of specialized typography. What if musicians > wanted their own MusicML too? > > 1.2. MathML reinvents the wheel, poorly. A suitable subset of TeX (not > the entirety of TeX, as that is a huge, single-implementation technology > that reputedly only Knuth ever fully understood) was the right choice all > along, because: > > 1.2.1. TeX is already the universally adopted standard --- and > already was long before MathML was invented. Check for yourself on > http://arxiv.org/ , where most new math papers are uploaded --- pick any > article, then "other" formats, then "Source": you can then download TeX > sources for almost every article. > > 1.2.2. TeX is very friendly to manual writing, being concise and > close to natural notation, with limited overhead (some backslashes and > curly braces), while MathML is as tedious to handwrite as any other > XML-based format. An example is worked out at > http://en.wikipedia.org/wiki/MathML#Example_and_comparison_to_other_formats, > where the solution to the quadratic equation is one line of TeX versus > 30 > lines of MathML! > > 1.2.3. An important corollary of being very close to natural notation > is that TeX can be nearly trivially "read aloud". That means that it offers > a particularly easy accessibility story. No matter what mechanism is used > to graphically display equations, providing the TeX source (similarly to > images alt text) would allow anyone to quickly read it themselves without > any kind of software support; and screen reading software could properly > read equations with minimal TeX-specific support code. For example, TeX > code such as "\int_0^1 x^2 dx" can be readily understood by any human with > basic TeX exposure (which is nearly 100% of mathematicians) and can be > easily handled by any screen reader that knows that \int should be read as > "integral" and that immediately after it, _ and ^ should be read as "from" > and "to" respectively. > > *** > > 2. Reasons why even if MathML had ever been a decent idea, now would be the > right time to drop it. Summary: never really got traction, and the same > rendering can now be achieved without MathML support. > > 2.1. MathML never saw much traction outside of Mozilla, despite having > been around for a decade. WebKit only got a very limited partial > implementation recently, and Google removed it from Blink. The fact that it > was just dropped from Blink says much about how little it's used: Google > wouldn't have disabled a feature that's needed to render web pages in the > real world. Opera got an implementation too, but Opera's engine has been > phased out. > > 2.2. High-quality mathematical typography in browsers is now possible, > without using MathML. Examples include MathJax ( http://www.mathjax.org/ ), > which happily takes either TeX or MathML input and renders it without > specific browser support, and of course PDF.js which is theoretically able > to render all PDFs including those generated by pdftex. Both approaches > give far higher quality output than what any current MathML browser > implementation offers. > > *** > > 3. Proposals > > Assuming that there will be agreement to drop MathML, I can see us doing > either of two things: > > 3.1. Either just drop MathML support; the assumption would be that > current solutions not requiring specific browser support, such as MathJax > or PDF.js, are sufficient; > > 3.2. Or drop MathML support and create a new specification, that would > be based on a suitable subset of TeX. > > In both approaches, distributing TeX source code alongside with a page is > highly desirable because it is the preferred source form of most math > content and because it enables good accessibility as discussed above. In > the 3.1 approach, that would be like alt text on images: something that > many authors would omit in practice. In the 3.2 approach, that would be the > document itself, which means that it couldn't be neglected. > > The big problem with 3.2. is the same issue as we described in 1.1: any > math-specific system may well be over-specialized. Then again, TeX is not > exclusively restricted to math typography, and it has been used for e.g. > music typography before. So to some extent that I haven't precisely figured > yet, the 1.1 overspecialization against MathML may not fully apply against > a TeX-based solution. > > Benoit > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
