* 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
