Hi everyone, As said in a previous message, MathML layout refactoring is in progress [1] and I'd like to use this opportunity to propose removing support for the menclose notation radical.
More context: In MathML3 there are three ways to write roots: 1) <msqrt> child1 child2 ... child3 </msqrt>, equivalent to the LaTeX expression \sqrt{child1 child2 ... child3} i.e. square root of "child1 child2 ... child3". 2) <mroot> child1 child2 </mroot>, equivalent to the LaTeX expression \sqrt[child2]{child1} i.e. "child2"-th root of "child1". 3) <menclose notation="radical"> child1 child2 ... child3 </menclose>, equivalent to 1) Currently 1) and 2) share an implementation in the RenderMathMLRoot class. That implementation relies on anonymous renderers and flexbox layout and has many issues with dynamic changes of child list, style, zoom etc. However, I've uploaded a patch to do a complete refactoring of RenderMathMLRoot in bug 153987 [2] which solves these issues. The menclose element definitely needs a clean rewriting too. In particular, 3) is implemented by appending an anonymous RenderMathMLRoot child in which we put all the other children ; and again dynamic changes are not handled very well . I have uploaded a patch to bug 155019 [3] in order to completely rewrite the menclose implementation and I decided to just remove support for menclose notation radical instead of trying to reuse RenderMathMLRoot. I expect this removal to be safe for the users given that (except in examples and tests) I've always seen 1) preferred over 3) in math documents. The only rationale for 3) would be to write overlapping notations (e.g. <menclose notation="radical circle horizontalstrike">) but again I'm not aware of any concrete use case for that and it's always possible to nest <msqrt> and <menclose> to get similar rendering. Finally, note that the accessibility code does expose the radical notation and my patch for bug 155019 does not affect that code. I plan to ask the same to Mozilla developers (FYI in Gecko, 1) and 3) are implemented in the same class but 2) is implemented in a separate class with duplicate code ; so it would also make sense for them to do a simplification). In the future, I also plan to ask to the Math WG to deprecate this notation and this is already done in the current draft of the MathML in HTML5 implementation note I wrote [4]. Anyway, the MathML recommendation is not too strict about supporting notation radical: "Conforming renderers may ignore any value they do not handle, although renderers are encouraged to render as many of the values listed below as possible" [5]. Frédéric Wang [1] https://lists.webkit.org/pipermail/webkit-dev/2015-December/027840.html [2] https://bugs.webkit.org/show_bug.cgi?id=153987 [3] https://bugs.webkit.org/show_bug.cgi?id=155019 [4] http://www.mathml-association.org/MathMLinHTML5/ [5] https://www.w3.org/TR/MathML3/chapter3.html#presm.menclose
signature.asc
Description: OpenPGP digital signature
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev