Here are a couple of reasons why dropping MathML would be a bad idea. (While I wrote this others made some of the points as well.)
* MathML is part of HTML5 and epub3. * Gecko has the very best native implementation out there, only a few constructs short of complete. * Killing it off means Mozilla gives up a competitive edge against all other browser engines. * MathML is widely used. Almost all publishers use XML workflows and in those MathML for math. Similarly, XML+MathML dominates technical writing. * In particular, the entire digital textbook market and thus the entire educational sector comes out of XML/MathML workflows right now. * MathML is the only format supported by math-capable accessibility tools right now. * MathML is just as powerful for typesetting math as TeX is. Publishers have been converting TeX to XML for over a decade (e.g., Wiley, Springer, Elsevier). Fun fact: the Math WG and the LaTeX3 group overlap. * Limitations of browser support does not mean that the standard is limited. >From a MathJax point of view * MathJax uses MathML as its internal format. * MathJax output is ~5 times slower than native support. This is after 9 years of development of jsmath and MathJax (and javascript engines). * The performance issues lie solely with rendering MathML using HTML constructs. * Performance is the only reason why Wikipedia continues to uses images. * JavaScript cannot access font metrics, so MathJax can only use fonts we'r able to teach it to use. * While TeX and the basic LaTeX packages are stable, most macro packages are unreliable. Speaking as a mathematician, it's often hard to compile my own TeX documents from a few years ago. You can also ask the arXiv folks how painful it is to do what they do. Other points * MathML has never seen paid browser development. All work (save code review) has been done solely by unpaid volunteers. If Mozilla was paying even a part time developer, Firefox would have had complete support years ago. * The same holds for Apple, Google and Microsoft. Yes, when you don't put any developers on the job, MathML implementations do not get better. * Google is even silly enough to kick out a hugely improved (albeit partial) implementation instead of landing the patches that fix that one remaining security issue -- while Apple doesn't have any problems with the same code. * Firefox has shown how productive the feedback loop from a partial implementation can be, attracting a number of volunteers over the years, pushing it forward a little bit each time. * MathML syntax is not as bad as people think but it takes getting used to (just like HTML). It's a bit like saying HTML is bad since markdown is much more human readable. Check out Dave Barton's jqmath, a serialization of MathML; with very little effort I find it as human readable as TeX. * TeX is *not* the de-facto standard for math. It is the standard for researchers in mathematics and very few related fields. Most mathematical content is not created by researchers but by technical writers and in the educational sector. And again: most TeX gets converted to MathML in publishing workflows. * MS Word and Libre Office produce MathML out of the box. Personal remarks MathML still feels a lot like HTML 1 to me. It's only entered the web natively in 2012. We're lacking a lot of tools, in particular open source tools (authoring environments, cross-conversion, a11y tools etc). But that's a bit like complaining in 1994 that HTML sucks and that there's TeX which is so much more natural with \chapter and \section and has higher typesetting quality anyway. I'm totally for MusicML! More generally, there are things like CellML, CML and other scientific standards. I'd encourage them to work towards becoming web standards, to prove that the web is truly the native place for all human communication. A statistical plot has no more reason to be an image than an equation -- it should be markup/data in the page and the browser should render it. Browsers may be the new printing press, but we are looking at Gutenberg's model here, not 20th century digital offset printing. Anyway, the MathWG has fought extremely hard for 15 years to make mathematics a first class citizen on the web. Certainly, MathML is only the beginning for math on the web. But abandoning it now will throw scientific content back 20 years. Personally, I don't want to wait for another Knuth to show up and fix the problem. Peter. On Sunday, 5 May 2013 16:40:30 UTC-7, Benoit Jacob wrote: > 2013/5/5 Wesley Johnston <wjohns...@mozilla.com> > > > > > > 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! > > > > > > This isn't exactly a fair comparison. I mean, its fair, but for equations > > > of any complexity (i.e. things you wouldn't find in a high school text > > > book) TeX can quickly become incredibly difficult (maybe more difficult > > > than MATHML) to manage. Most people I know who use TeX regularly have > > > developed fairly thick sets of macros to try and manage things. > > > > > > > Well, I have written hundreds of pages of TeX; for sure, some large > > equations would expand over more than one line of TeX, but I can't remember > > going over more than 5 lines of TeX source (without custom helper macros) > > per actual line of output, that that would be a really unusual case --- > > while the MathML example above has a ratio of 30 source lines to 1 output > > line. > > > > The fact that TeX furthermore allows macros shouldn't be considered proof > > that it's particularly hairy --- it's just something that people do for > > convenience/abstraction. > > > > There _are_ very hairy things with TeX, but they are not so much with math > > typography per se; instead, I'd say that TeX becomes hairy when one tries > > to use it beyond its primary domain of application. For example, one can > > draw diagrams, e.g. with the xypic package, and that can get really > > cumbersome and inexpressive. But that's not part of what I was suggesting > > could become part of the subset-of-TeX used to replace MathML. > > > > > > > > > > Given that TeX is already the standard in scientific publishing, I would > > > > find it very surprising if they complained about a TeX-based or TeX-like > > > > format ! > > > > > > I'm not sure this is true either. At least in the fields I was involved in > > > (solid state phsyics), MS Word had established itself as a broader > > > standard. That was primarily based on general ease of use and (more > > > importantly?) ease of collaboration (i.e. we could easily share a real > > > document back and forth that tracked changes/comments inside it). Using a > > > version tracking system would have been interesting... but I wasn't aware > > > of anyone doing it. > > > > > > > Ouch. I am glad I didn't work in a field where MS Word was in use for > > writing long and/or scientific documents. > > > > At least for the more mathematical sciences (math, mathematical physics, > > large parts of CS) I can say with confidence that TeX is ubiquitous. > > > > > > > > > > > > I always wanted to see MathML succeeded. There are plenty of things to > > > complain about in the format, but I think most of its problems stemmed from > > > a lack of implementations. It feels to me like another one of those > > > technologies (like flexbox or web components) that people need to reinvent > > > (with a few of the sharp edges rounded off) and try to sell as "new". Until > > > we have buy in from some other browser vendors on a new format though, I > > > don't think I understand why we'd kill off something that 1.) works and 2.) > > > AFAIK requires almost zero upkeep. Are teams spending a lot of time > > > upkeeping MathML code? > > > > > > > We agree: it does sound fair to wait for either a replacement, or agreement > > that no such technology is needed in browsers, or evidence that the > > maintenance cost is significant, before taking any decision to drop MathML. > > > > Benoit > > > > > > > > > > - Wes > > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
