# [webkit-dev] Proposal: remove menclose notation radical

Frédéric WANG fred.wang at free.fr
Thu Mar 10 03:45:04 PST 2016

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20160310/00dda7da/attachment.sig>