Let me just reply to a few points to keep this conversation manageable: 2013/5/5 <p.krautzber...@gmail.com>
> 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. > That MathML is part of epub3, is useful information. It doesn't mean that MathML is good but it means that it's more encroached than I knew. We don't care about "this is part of HTML5" arguments (or else we would support all the crazy stuff that flies on public-fx@w3...) > * 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). > JavaScript performance hasn't stopped improving and is already far better than 5x slower than native on use cases (like the Unreal Engine 3 demo) that were a priori much harder for JavaScript. > * The performance issues lie solely with rendering MathML using HTML > constructs. > * Performance is the only reason why Wikipedia continues to uses images. > Then fix performance? With recent JavaScript improvements, if you really can't get faster than within 5x of native, then you must be running into a browser bug. The good thing with rendering with general HTML constructs is that improving performance for such use cases benefits the entire browser. If you pit browsers against each other on such a benchmark, you should be able to generate enough competitive pressure between browser vendors to force them to pay attention. > * JavaScript cannot access font metrics, so MathJax can only use fonts > we'r able to teach it to use. > Has that issue been brought up in the right places before (like, on this very mailing list?) Accessing font metrics sounds like something reasonable that would benefit multiple applications (like PDF.js). > * 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. > I'm also speaking as a (former) mathematician, and I've never had to rely on TeX packages that aren't found in every sane TeX distribution (when I stopped using TeX on a daily basis, TexLive was what everybody seemed to be using). But that's not relevant to my proposal (or considering a suitable subset of TeX-plus-some-packages) because we could write this specification in a way that mandates support for a fixed set of functionality, much like other Web specifications do. > > > 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). > I'm concerned everytime I hear "native" as an inherent quality. As I tried to explain above, if something can be done in browsers without "native" support, that's much better. The job of browser vendors is to be picky gatekeepers to limit the number of different specialized things that require "native" support. Whence my specific interest in MathJax here. > > 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. > It would have been extremely easy to rebut such arguments as irrelevant and counter them by much stronger arguments why TeX couldn't do the job that HTML does. I am still waiting for the rebuttal of my arguments, in the original email in this thread, about how TeX is strictly better than MathML for the particular task of representing equations. As far as I can see, MathML's only inherent claim to existence is "it's XML", and being XML stopped being a relevant selling point for a Web spec many years ago (or else we'd be stuck with XHTML). > > 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. > That's our perspective mismatch right there. Application developers want features: nothing could be more natural. The job of browser developers is to say "no" unless the feature is really necessary for doing something important on the Web. That's why the MathJax part of our conversation, above, is the most useful one. Cheers, Benoit > > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
