Re: [MathML4] Removal of the menclose notation "radical"

Hi Frederic,

I don't see why there would be inconsistencies in implementation.   A
reasonable developer would just have <msqrt> call the same code as
<menclose notation="radical">.

>From a software engineering point of view, I would think it would make more
sense to remove <msqrt>.   But from a "give the people what they think they
want" point of view, I would think we need to keep it.

Stephen


On Tue, Jul 26, 2016 at 3:29 AM, Frédéric WANG <fred.wang@free.fr> wrote:

> Hi everybody,
>
> Continuing on proposal for MathML4, there are two equivalent notations
> for square roots:
>
> * <msqrt> child1 child2 ... child3 </msqrt>
> * <menclose notation="radical"> child1 child2 ... child3 </menclose>
>
> The latter does not bring anything new but duplicate code or
> inconsistencies in implementation. In WebKit, the msqrt and mroot
> elements share implementation and menclose@radical was implemented by
> creating anonymous nodes. In the past, this kind of implementation has
> led to rendering, performance and design/security issues. During phase 1
> of our refactoring [1], we thus removed support for menclose@radical. In
> Gecko, the msqrt and menclose elements share implementation but then
> mroot has duplicate logic, which is bad and Gecko should probably be
> aligned on WebKit here.
>
> So we would like menclose@radical to be removed in future versions of
> MathML (it is optional in MathML3 anyway). We expect this removal to be
> safe for the users given that (except in examples and tests) msqrt is
> always preferred over menclose@radical in math documents. The only
> rationale for menclose@radical would be to write overlapping notations
> (e.g. <menclose notation="radical circle horizontalstrike">) but again
> we are not aware of any concrete use cases for that and it's always
> possible to nest <msqrt> and <menclose> to get similar rendering without
> overlapping notations.
>
> Frédéric, for the Igalia Web Platform team
>
> [1] https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring
>
>
>
>