We're getting distracted by the comparison with TeX and the discussion of MathML's relative merits. My bad: I obscured my message by starting two conversations at once (1.1 and 1.2 in my initial email).
I happily concede this round, given that most people disagree with me about TeX in this thread. Can we focus on the other conversation now: should the Web have a math-specific markup format at all? I claim it shouldn't; I mostly mentioned TeX as a "if we really wanted one" side note and let it go out of hand. How many specific domains will want to have their own domain-specific markup language next? Chemistry? Biology? Electronics? Music? Flow charts? Calligraphy? I suspect that when people start asking for that, we'll quickly have to start saying "no", and at that point, the exception made for math will seem unjustified. I understand, from Boris' email, that there are nontrivial performance issues associated with relying on generic HTML layout to render math. And API issues associated with querying font metrics from JavaScript. But surely it must be possible to overcome these issues, and that would benefit entire classes of content, not just math. If tomorrow a competing browser solves these problems, and renders MathJax's HTML output fast, we will obviously have to follow. That can easily happen, especially as neither of our two main competitors is supporting MathML. Benoit 2013/5/5 Benoit Jacob <jacob.benoi...@gmail.com> > 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
