W3C home > Mailing lists > Public > www-math@w3.org > February 2013

Re: Help get math turned back on in Chrome

From: Frédéric WANG <fred.wang@free.fr>
Date: Fri, 08 Feb 2013 09:00:18 +0100
Message-ID: <5114B092.7040108@free.fr>
To: www-math@w3.org
Hi all,

It seems that we all agree about the importance of MathML for education 
and science on the Web in the future. It's good to recall here that the 
Web was invented at the CERN in order to share scientific documentation 
and that the openness & exchange principles inherited from research was 
the key of its success. Certainly, Google engineers have strong 
mathematical background and, as Dave said, that's incredible they don't 
dedicate much effort to MathML. I doubt that voting for the bug will 
make them change their mind, but that won't make the situation worse, 
anyway. People mentioned two projects I've been involved (MathJax and 
Mozilla) so I think that could be useful if I add my point of view on this.

First, I think it is very bad to see MathJax as just a javascript 
rendering engine for MathML or even a rendering engine + a TeX parser. 
Certainly, that's currently the main features that make people use it 
but that's not all. Otherwise, the rendering engine is essentially 
already done and many people on this list have alternative projects to 
write or render MathML. So that would actually counterproductive if the 
goal was just to write yet another project to replace these alternatives 
and to convince users and browser vendors that MathML is not needed, 
since MathJax can be used as rendering engine. Fortunately, that's not 
the case and the goal of the MathJax team is much more ambitious. 
MathJax has features to let the user easily configure the Website and in 
particular to load only components that fit his need (AsciiMath, TeX, 
MathML input ; NativeMML, SVG, HTML-CSS output, menu, zoom etc), it 
allows to attach style to formulas via the classical CSS, has a 
Javascript API to let developers write advanced Web applications, it 
workarounds browser bugs (even those for the native MathML), has a CDN 
service so that any user can easily install it, provides Web fonts and 
so forth We have many other plans like implementing graphics packages, 
adding more input modes, improving localization & accessibility, 
integration in Wikipedia etc So from this point of view, I see MathJax 
has a way to really solve the chicken-and-the-egg by building a 
community that starts to really use the Web (in contrast to the 
classical researcher home page = a repository with pdf papers to 
download) and provides feedback to spec authors and browser developers. 
Of course, I don't say MathJax is perfect and actually I think MathJax 
default output could progressively switch to native MathML when it is 
better implemented and that would solve many of the shortcomings that 
Dave mentioned, while still continuing to provide a convenient 
environment for Web authors and app developers.

Next, someone mentions Peter's idea that we are just at the beginning. 
We can compare the situation as the one of HTML in browsers. At the 
beginning, people could only create static pages with a rudimentary 
design. We had to rely on HTML tables and other hacks to do the layout 
while browser vendors started to invent CSS & Javascript features. Then 
CMS, wiki syntax etc begin to appear so that people do not need to care 
about the fact that "HTML+CSS is too verbose to be written by humans". 
It took time to finally standardize all the Web features we use 
nowadays. Browser vendors are still inventing some new advanced features 
but there is at least a set of common features that can be used safely 
across all the Web browsers, without having to say that "this site is 
optimized for ... with a screen resolution of ...". With MathML we have 
at least a standard for writing mathematical formulas, we have many 
tools to easily write MathML (e.g. from LaTeX) and to integrate it in 
your Web site (e.g. MathJax) without having to "optimized" it for a 
given user platform. Isn't it time for browser vendors to enter the game 
and invest a little money to obtain a decent MathML support? Or should 
we continue to "layout our pages with HTML tables", that is to ask 
people to install plugins or fonts, to rely on the MathJax output in 
ebook & Website or to use other images and other hacks that have been 
invented to workaround the lack of MathML support?

Finally, Dave mentioned the role that Mozilla could play to encourage 
competitions (cf the parallel with HTML+CSS above and remember the 
Microsoft monopole not so long ago). I can't speak for Mozilla 
Corporation, but the impression I have is that MathML is not the 
priority for them, as they have a much better support than any other 
rendering engines and they prefer to focus on other areas where the 
competition seems more important (mobile, speed, new Web features etc). 
I don't think the managers ever realize that they could take advantage 
of MathML and just consider the MathML volunteers as any other small 
groups in the Mozilla community. Technically, Google's main contribution 
to browsers and mobile devices was to demonstrate that the rendering 
engine (especially Javascript) could be very fast
and users are now familiar with this speed. So if in the short term, 
MathJax is enabled in Wikipedia & other popular Web sites and if 
Firefox's native MathML is enabled by default in MathJax, that could 
definitely be a real difference for the users when the page takes less 
than one second to display in Firefox and several seconds or even 
minutes in Chrome or Webkit-based mobile devices. Moreover, Mozilla's 
bet is that building an environment for mobile devices based on Web 
openness and technologies will attract app developers and users that are 
tired of iOS & Android proprietary APIs. As I said, one of MathJax's 
goal is to provide such a Web-based framework to let authors write math 
applications. Again, that would be a real benefits for these authors if 
they use the MathJax framework + Gecko native MathML rather than trying 
to slim down MathJax or workaround security restrictions as this is 
unfortunately currently the case for Webkit-based mobile devices...

Frédéric Wang
Received on Friday, 8 February 2013 07:59:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:45 UTC