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

[bugzilla-daemon at webkit.org]

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





--- Comment #11 from Frédéric Wang <fred.wang at free.fr>  2012-02-17 13:00:39 PST ---
> 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 think the idea of the data is the following. If you have

<munder>
  <msub>
    <mo>→</mo>
    <mi>0</mi>
  </msub>
  <mtext>text</mtext>
</munder>

Each time you must redraw the arrow (for example when you modify the mtext, or zoom, or resize the window...), you can directly use the pointer instead of having to call a function to find it. Of course, this does not seem very helpful on this trivial example and one may argue that the embellished operator subtree is not really deep in general, which is certainly true. But the point is that we have actually more data to compute than simply the pointer to the core frame and the data may depend on many other elements/attributes so that's better to compute the whole thing once and let the frames communicate their infos to each other. So the drawback of the data is just a slight memory overhead but it is intended to make the whole thing faster. I don't claim that it is actually true in practice, I didn't make experiments to verify this assertion and didn't write the Mozilla code. Again, I don't know the Webkit code and just gave you a suggestion. Webkit folks know better than me which design is appropriate for their code.


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


Well, I think there are other deeper reasons for MathML not having been used as much as other web languages than this <mrow> property,  but that seems a bit off topic... And BTW this property seems quite reasonable to me actually, since <mrow> is only here to group elements. If you group a single element, I can't see any reason to change its properties (of course this grouping is useless, but you can't prevent people from writing/generating such code)...

> 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 don't know which elements Webkit implements or not, I just wanted to make you aware of the embellished op details. Obviously, that makes sense to make embellished op work just for the elements that are already implemented in Webkit.


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

I can't speak for Webkit, but I think the purpose of the review system is to ensure code quality (and that's already a work for Webkit people to do that...). Sometimes it is best not to go too fast and to do things carefully... Currently, code refactoring is needed in Mozilla MathML code because things were implemented in a very bad way (for example attributes added to the DOM to simulate style properties). Similarly, my comparison with the MathML REC and Mozilla code was intended to help you, not to delay your work on MathML. You'll have to find the balance between prioritizing the things that have to be implemented and to deliver a good MathML support for Webkit...

Also, there are tools to handle several patches at the same time (for example, Mercurial has an extension called "Mercurial Queues"). This is very convenient to break down the work in small pieces but still being able to modify a large portions of code simultaneously. You should definitely have a look to them.

Good luck for your MathML work in Webkit!

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