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

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 
comments:

* 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.

Regarding your CSS wishes:

* 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 
https://code.google.com/p/chromium/issues/detail?id=152430#c85).

-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic