# Re: [LaTeXML] Mozilla Science Lab Multi-Site Sprint

From: Frédéric WANG <fred.wang@free.fr>
Date: Fri, 13 Jun 2014 10:59:24 +0200
Message-ID: <539ABD6C.3070107@free.fr>
To: William F Hammond <gellmu@gmail.com>, LaTeXML project <project-latexml@lists.jacobs-university.de>, "www-math@w3.org" <www-math@w3.org>
Le 12/06/2014 21:47, William F Hammond a écrit :
>
> On Thu, Jun 12, 2014 at 8:33 AM, Raniere Silva <raniere@ime.unicamp.br
> <mailto:raniere@ime.unicamp.br>> wrote:
>
>     Mozilla Science Lab is organizing a Multi-Site Sprint that will happen
>     on July 22-23. [1]
>
>
> I'd like to mention my hot-off-the-press "Wishes for CSS":
> http://www.albany.edu/~hammond/demos/purecss/cssWishes.html
> <http://www.albany.edu/%7Ehammond/demos/purecss/cssWishes.html>
>
> For a picture of CSS flexible box scatter art (so definitely not
> table-based) with some mathematical decorations I might offer
> http://www.albany.edu/~hammond/demos/purecss/fscratch.html
> <http://www.albany.edu/%7Ehammond/demos/purecss/fscratch.html>
> for those using a suitably recent browser that supports new CSS,
> including flexible boxes, and web fonts.  (I know that recent Chrome,
> Firefox, and Opera are good.  I don't have IE and have no report, but
> maybe IE 11 is OK -- does anyone know?)

Bill,

You've written in many places to get feedback on your CSS-based
rendering. I refrained from commenting because I didn't want to upset
you, but I'm obviously in favor of native MathML implementation and
focusing on MathJax, static CSS-based stylesheet or other hacks is just
a lost of time in my opinion. That shows again the idea stated by
someone else on the Math WG mailing list after Google's decision to drop
native MathML that math people are not able to work together on a clean
native implementation and each one tries to invent its method. FYI, I
only restored Opera's stylesheet to have a simple workaround that is not
as heavy as MathJax for use in MDN, but I personally don't believe it is
the future (for MathJax's position, see
http://programming.oreilly.com/2013/11/mathml-forges-on.html). Some

* You made the claim somewhere else that relying exclusively on CSS will
allow to speed up native MathML rendering. I agree that relying on
existing CSS properties as much as possible helps native MathML (that's
what Gecko and WebKit do) but inventing new CSS properties or box models
only for MathML's sake is not useful. Basically, a CSS property =
"parsing of rules + managing CSS internal representation + native
implemention of the property" ; so it can not be more efficient than
"native implementation only". Moreover, it becomes much more difficult
to be accepted by browser reviewers or CSS working group, if the
property is not useful for other things than math. That's what Opera did
with the "table-baseline" property but the CSS3 Tables Module is now
abandoned and so Opera's stylesheet no longer works in any browser. I
believe the best would be to optimize native MathML (that's what was
done in Gecko by cleaning up the mstyle code and there is now discussion
to simplify the stretching code once people move to OpenType MATH fonts
see https://bugzilla.mozilla.org/show_bug.cgi?id=1009582), although I
think that's not too much a priority for most people since they even
accept MathJax's slowness for now.

* The flexbox-based approach is exactly what WebKit's native MathML does
(that was Dave Barton's idea btw), it also has all the features in your
"css wishes" and is certainly as fast. However, you said in a previous
message that you find WebKit's implementation very poor. I agree it's
not the best at the moment, but it is still better than the static
CSS-only approach, so I don't see the improvement here. Instead of
inventing new CSS rules, why not trying to help improving the WebKit
code so that it can be can a sufficient level and integrated back to Blink?

* You said in a previous message that it is less evil for you to have a
library like MathJax hiding all technical details to users than to teach
to Web authors how to use Web fonts properly or to tell users how to
install math fonts. I personally think that with modern OpenType MATH
fonts that integrate all info into one file, it's not more complicate to
use one stylesheet of https://github.com/fred-wang/MathFonts than to use
a script to enable MathJax or a stylesheet for the CSS fallback. Also, I
expect OpenType MATH fonts to become installed by default on most
operating systems (that's already the case on Windows or on systems with
a TeX distribution) so that users don't need to worry about that.

* Baseline designations in flexible boxes: as said above, this would add
new CSS properties and parsing rules. I don't know whether or not it
could be integrated in the CSS standard. However, this is trivially done
in WebKit MathML by overriding the RenderMathMLBlock::baselinePosition()
C++ function, so this is of no help for WebKit MathML (or to get
something better than WebKit MathML).

* Reverse Parent/Child Selectors: I guess there is a good reason why
they don't exist, but you'd better ask to the CSS WG. As I see, to know
if an element matches "A > B" one only has to test its parent while to
know if an element matches "B < A", one would have to test all its
children. So the work necessary for things like "D < C < B < A" could
grow exponentially with respect to the number of elements, while it is
still linear for "A > B > C > D". Also rules like * or :nth-child are
considered inefficient and Blink has C++ assertions to ensure that they
are not used in user agent stylesheet (see
https://codereview.chromium.org/138383003#msg3). In native MathML or
MathJax, it's easier to use appropriate function to test the local
surrounding of the MathML tree when CSS selectors are not enough.

* More Options for Border Sides: I believe operator stretching is one of
the most difficult thing for someone willing to use CSS-only
constructions. You can certainly do something in some special cases like
"math-radical" but that won't work in general. Opera only supported a
few stretchy operators and only for the mfenced element. As a
comparison, MathJax needs to load big Javascript files with all the font
data in order to do that properly. This was one of the most serious
issue with WebKit MathML which is hopefully going to be addressed when
the OpenType MATH support is ready (at the moment it works only on
Linux, see https://bugs.webkit.org/show_bug.cgi?id=133603 for the
tracking bug).

Finally, note this optimist end of Murray's blog post
http://blogs.msdn.com/b/murrays/archive/2014/04/27/opentype-math-tables.aspx:

"Internet Explorer uses LineServices
<http://blogs.msdn.com/b/murrays/archive/2006/11/15/lineservices.aspx>,
the component that Office apps call to layout math zones with the help
of the tables to achieve TeX typographic quality. But since IE doesn’t
currently enable the LineServices math handler, the math it displays in
the MathML torture test doesn't resemble math. Hopefully that will change."

So naively ignoring technical details, that sounds like only a
"political decision" from the IE team to enable the LineServices math
handler. There is of course still some work to make things work in
Gecko, WebKit and Internet Explorer, but I believe if they can get some
MathML rendering based on OpenType MATH and if such fonts become
popular, we could have consistent implementations. Then perhaps the
decision could be revised in Blink (see