[Webkit-unassigned] [Bug 78617] MathML internals - embellished operators, getBase() accessor functions

Fri Feb 17 10:38:39 PST 2012

https://bugs.webkit.org/show_bug.cgi?id=78617

Dave Barton <dbarton at mathscribe.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |darin at apple.com

--- Comment #10 from Dave Barton <dbarton at mathscribe.com>  2012-02-17 10:38:38 PST ---
I asked Neil Soiffer, arguably the world's #1 authority on these matters (MathML committee major author for 15 years, Mathematica front end & IE MathPlayer implementer, authority for Frédéric Wang and others on w3c's mathml mailing list), about the rules for mrow and embellished operators in MathML and got this response:

``It's hard to remember back why all of the things that are in MathML are in there.  Some have good solid technical reasons and some were political compromises -- I hate mfenced, which is duplicates other things and isn't as powerful and causes problems for things like CSS because drawn items are buried in attributes.  Anyway...

mrow with one arg were added because authoring tool editors felt that it was more natural to always have mrows around subexpression, such as a numerator of a fraction.  Hand authoring, which was still popular (and remains popular by HTML developers to this day) pushed towards not always requiring the mrows.  That's also the reason for the implicit mrows in some places such as msqrt.  In the implementations I've done, I've typically "normalized" them away so the rendering code never sees it.  This normalization is either explicit (tree is changed) or virtual via a "getChild" method that checks if the child is an mrow with a single child, and if so, calls itself recursively.

The embellished operators rules are a bit complicated, but grew out of use cases.  I think (not 100% positive -- I'd need to check the code), that like mrow, embellished operators were virtualized in my code in the sense that there is a "isOperator" call that checks to see if something is a script (etc), and if so, calls itself on the base of the script.  In that way, they turned out not to be much of an exception to the layout logic -- any value you ask for of  an operator could be asked of an embellished operator without needing to know about details of the embellished operator.  I will admit that in my linebreaking code, I repeatedly forgot to call the higher level function and that led to many bugs, all of which were trivial to fix but still bugs nonetheless.  I do remember there being a lot of discussion about the embellished operator/mrow/space-like children rule, but it was too long ago to remember the rationale.  If needed, I could go through the list archives...''

So it sounds like Neil's probably gone the virtual function route for tracking embellished operators, instead of the Mozilla method of adding extra data. The extra data has the drawback of needing to be updated whenever the DOM changes. I'm not sure it really saves much time in practice.

I find all this fascinating. The whole <mrow> of one argument must be equivalent in all ways to the argument itself seems crazy to me. This would be like saying that <span> of one argument must behave like the argument alone in all ways, e.g. CSS child selector rules. This would be nuts, IMHO. To justify it by saying that the numerator argument to <mfrac> should always be an <mrow> in some editor is like saying everything inside a <p> tag should always be wrapped in a <span>. This just doesn't make any sense to me. Perhaps this is part of why MathML never caught on in 15 years. I understand that it's our job to implement all of the spec, not just the parts we like, but I also think eventually someone from WebKit should be on the w3c mathml committee and ask about deprecating some of these features (bugs?) from 15 years ago, when for instance CSS didn't even exist.

But the real point is we are a long way away from even worrying about things like this. WebKit doesn't yet have mmultiscripts, semantics, mstyle, mphantom, mpadded, or maction elements, or almost any kind of space-like element (and is arbitrary mtext really space-like?). Thus almost all the clauses about embellished operators that Frédéric Wang refers to don't yet apply to us. I have flagged "embellished operators" as a FIXME comment in the code in this patch, and I suppose we could file a bug for it also, but there are dozens of other things in MathML that we don't have yet either, and we don't have bug reports for them.

I just want to fix WebKit's stretching of operators, including ones with subscripts/superscripts/underscripts/overscripts, for example integral signs with limits. I'd like to do (most of) this in my next patch, eliminating the current nonOperatorHeight() and hasBase() functions entirely, which don't conform at all to either the MathML spec or standard mathematical typesetting.

WebKit's MathML implementation is currently minimal (a partial implementation), nonstandard, buggy, and perhaps insecure. In my opinion, we'll never fix all this if we insist on small patches, and then compare each one to everything in Mozilla and the MathML spec. Even if I or someone else was able to put in unlimited hours of programming for free, no one at webkit would review or commit the patches. The current system is difficult enough - break patches into tiny pieces, and then hope they will be reviewed within a few days each. Not only will it take years to implement MathML at this pace, it's just plain hard to program when taking breaks of a few days or longer between each tiny bit of programming.

I think we need to either review this patch + or - soon, or else admit that this development model isn't working. Do we need to wait for WebKit companies to decide whether MathML is worth paying a committer to read parts of the MathML spec and spend a few hours per week reviewing patches, to help sell devices to literally hundreds of millions of students, scientists, and engineers that will want to use MathML in WebKit in the next few years? I respectfully await your reply.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.