On Sunday, 5 May 2013 16:38:39 UTC+1, Benoit Jacob wrote: > Hi, > > > > Summary: MathML is a vestigial remnant of the XML-everything era, and we > > should drop it. >
As can be seen in the integration into HTML(5) nothing in MathML requires an XML surface syntax. > > > *** > > > > 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. TeX is designed for a situation in which the author has full control over fonts and page size. It is not designed at all for a web-like scenario, in particular TeX has no support for linebreaking of displayed mathematics which is particularly important with small screens etc. Also of course classic TeX has no support for Unicode fonts. There are Unicode variants (luatex and xetex) and experimental support for Unicode math fonts (unicode-math fonts) but all these are relatively unstable development software and hardly well-established standards. > > > > 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? > > Mathematics plays a central role as part of the _textual_ vocabulary of scientific and educational literature. Music is of course important but musical notation does not have to interact with textual paragraphs in the same way. > > 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: It does not re-invent TeX: it is different. > > > > 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. TeX is the standard in some fields for _author submission_ although even in scientific fields other formats notably Word are surprisingly (perhaps) common. Also other than self-publishing mechanisms such as arxiv many scientific journals do _not_ use TeX for publishing and even if they accept tex input they convert in house to xml/mathml workflows (thus mathml is a more natural publishing format) > > > > 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! > > Probably true but not very relevant. HTML is more verbose than wiki syntax for the same reasons. > > 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. > > The accessibility implementations of MathML (notably MathPlayer) rather refute the suggestions that it is easier to get accessible renderings from Tex. rather the reverse is true. > > *** > > > > 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. > > MathML is a standard part of ODF (OpenOffice etc) it is supported in clipboard in Word and the rest of the MS Office suite. It is a standard part of epub3. It is supported in many typesetting systems used by journals. It is supported on import/export in maple and mathematca, just to name a few. In contrast TeX is notoriously difficult to process by anything other than TeX: latex2html/tex4ht/latexml do a remarkable job but are inherently fragile and incomplete. > > 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. > If you mean "in web browsers" firefox and IE+MathPlayer are the two main implementations it is true with less complete support in Safari and Opera. See the comment above for traction in MathML in other aspects. > > 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. > MathJax (or any javascript) rendering is clearly slower and harder to interact with than a native implementation that maps directly to the DOM > > > *** > > > > 3. Proposals > > > > Assuming that there will be agreement to drop MathML, I can see us doing > > either of two things: > > Hopefully there will be no such agreement, it would be a massively detrimental step for the scientific and educational use of the web. > > 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; > They are not. PDF in particular is not an ideal format on the web for so many obvious reasons. > > > 3.2. Or drop MathML support and create a new specification, that would > > be based on a suitable subset of TeX. > > It is hard to think of any advantages that would have. > > 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 David _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
