Re: [MathML4] Deprecation/Removal of the mfenced element

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--CnNpgxUS1mf00CB61sdS289nc1leVteEv
Content-Type: multipart/mixed; boundary="h01j48f9R4QuRabH5qHVgSJUJ6qVofp7A"
From: =?UTF-8?B?RnLDqWTDqXJpYyBXQU5H?= <[email protected]>
To: [email protected]
Message-ID: <[email protected]>
Subject: Re: [MathML4] Deprecation/Removal of the mfenced element
References: <[email protected]>
 <CALozgshVE0bwjs9LqsnvVNYX=b_bLjOrcM=dNX4=_7LeB0A3fA@mail.gmail.com>
 <[email protected]>
 <[email protected]>
In-Reply-To: <[email protected]>

--h01j48f9R4QuRabH5qHVgSJUJ6qVofp7A
Content-Type: multipart/alternative;
 boundary="------------8454FE0795D4C7D794796C5F"

This is a multi-part message in MIME format.
--------------8454FE0795D4C7D794796C5F
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 26/07/2016 =C3=A0 21:11, Daniel Marques a =C3=A9crit :
> I also like the "mfenced". Vertical stretchies with <mo> are difficult =
to
> understand from the point of view of someone who uses a formula editor.=

> What people understands when editing is that an open and close parenthe=
sis
> grows according to what's inside. Thus, for people who do editors, the
> preferred feature is the mfenced.
You can definitely use mfenced internally in a formula editor if that
improves the UI. However, if that editor is not able to import/export
from and to the canonical form described in the MathML recommendation
then that's definitely a big flaw in that product.

> There is also a VERY important aspect which is BACKWARD COMPATIBILITY.
> There are plenty of formulas that use mfenced. Both Microsoft Word and
> WIRIS (I'm not able to test MathType at this moment) use the mfenced ta=
g
> for stretchy parenthesis.
>
> Losing backward compatibility will result that a lot of formulas stop
> working. This would yield a lack of trust on the MathML specification.
> Please do not commit that mistake!
MathML is not implemented in Edge or Blink, so we currently have to use
converters to other formats in order to display formulas in all web
rendering engines. Having programs to put MathML in a canonical form for
old documents before delivering to web engines is not worse in my
opinion. And there is already a lack of trust in the MathML
specification because not all browser vendors have shown interest in
MathML until recently, because some Math WG members and contributors
seemed more interested in a theoretical standard than to consider
concrete feedback from web engines developers, because the current
MathML specification is too vague to implement high-quality math
rendering or handle subtle rendering aspects and because the official
MathML test suite is not runnable in browsers' test framework in its
current form. The quick work done for the past few months on WebKit and
Blink at Igalia showed that by extending / cleaning up the MathML
specification and rewriting the test suite, things become much easier
for web engines developers to understand, implement and test and for
browser vendors to accept a proposal that integrates well in their code
base. The goal of the discussion is to (re?)open a constructive
collaboration with people involved in the MathML specification and with
web engines developers.

To come back to mfenced, it has always been the source of bugs in Gecko
and WebKit that have added maintenance cost. And it has been a burden
during our refactoring in WebKit: we have spent and continue to spend *a
lot of time* to avoid breaking the current support and this is as much
time that could have been spent on working on more important aspects of
the MathML implementation. So although there is no rush for removing
that support, we believe it is important to report this issue so that it
can be taken into account in the long term. As I said in the menclose
thread, with the new layout rules in Blink it's very unlikely that
WebKit's mfenced implementation can be accepted by Google reviewers and
we do not plan to try it.

--=20
Fr=C3=A9d=C3=A9ric Wang


--------------8454FE0795D4C7D794796C5F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 26/07/2016 =C3=A0 21:11, Daniel Mar=
ques a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:[email protected]"
      type=3D"cite">
      <pre wrap=3D"">I also like the "mfenced". Vertical stretchies with =
&lt;mo&gt; are difficult to
understand from the point of view of someone who uses a formula editor.
What people understands when editing is that an open and close parenthesi=
s
grows according to what's inside. Thus, for people who do editors, the
preferred feature is the mfenced.
</pre>
    </blockquote>
    You can definitely use mfenced internally in a formula editor if
    that improves the UI. However, if that editor is not able to
    import/export from and to the canonical form described in the MathML
    recommendation then that's definitely a big flaw in that product.<br>=

    <br>
    <blockquote
      cite=3D"mid:[email protected]"
      type=3D"cite">
      <pre wrap=3D"">There is also a VERY important aspect which is BACKW=
ARD COMPATIBILITY.
There are plenty of formulas that use mfenced. Both Microsoft Word and
WIRIS (I'm not able to test MathType at this moment) use the mfenced tag
for stretchy parenthesis.

Losing backward compatibility will result that a lot of formulas stop
working. This would yield a lack of trust on the MathML specification.
Please do not commit that mistake!
</pre>
    </blockquote>
    MathML is not implemented in Edge or Blink, so we currently have to
    use converters to other formats in order to display formulas in all
    web rendering engines. Having programs to put MathML in a canonical
    form for old documents before delivering to web engines is not worse
    in my opinion. And there is already a lack of trust in the MathML
    specification because not all browser vendors have shown interest in
    MathML until recently, because some Math WG members and contributors
    seemed more interested in a theoretical standard than to consider
    concrete feedback from web engines developers, because the current
    MathML specification is too vague to implement high-quality math
    rendering or handle subtle rendering aspects and because the
    official MathML test suite is not runnable in browsers' test
    framework in its current form. The quick work done for the past few
    months on WebKit and Blink at Igalia showed that by extending /
    cleaning up the MathML specification and rewriting the test suite,
    things become much easier for web engines developers to understand,
    implement and test and for browser vendors to accept a proposal that
    integrates well in their code base. The goal of the discussion is to
    (re?)open a constructive collaboration with people involved in the
    MathML specification and with web engines developers.<br>
    <br>
    To come back to mfenced, it has always been the source of bugs in
    Gecko and WebKit that have added maintenance cost. And it has been a
    burden during our refactoring in WebKit: we have spent and continue
    to spend *a lot of time* to avoid breaking the current support and
    this is as much time that could have been spent on working on more
    important aspects of the MathML implementation. So although there is
    no rush for removing that support, we believe it is important to
    report this issue so that it can be taken into account in the long
    term. As I said in the menclose thread, with the new layout rules in
    Blink it's very unlikely that WebKit's mfenced implementation can be
    accepted by Google reviewers and we do not plan to try it.<br>
    <pre class=3D"moz-signature" cols=3D"72">--=20
Fr=C3=A9d=C3=A9ric Wang
</pre>
  </body>
</html>

--------------8454FE0795D4C7D794796C5F--

--h01j48f9R4QuRabH5qHVgSJUJ6qVofp7A--

--CnNpgxUS1mf00CB61sdS289nc1leVteEv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXmFMqAAoJEL8nnpULUzQOSBMP/jbn8HvmLbouuBsdH8FNqn5k
5qBGZnHrloIo9MrD3Oi6Wm7ydGABCsZcEcc/i5uOOPZ4JEky0NFsOSiwP27IbDiv
h/fLc892TsGu+3d1Q7q+0bUcr/QdcqfvZU3vLDTdvC9RA1GK/FWWNHNRyGTp5u1l
soc0qyDPKnwBbhn5DRLg1He/4gaDvP899LCMSEfFFovNSbTzERSCjFFVzh/v7jh0
p61J89R5zvoJXvpegNvYj5dglf2OBLsakvr3X9BciEi2MTRA4hQzqSngYr6+/ARM
4L5h9zh8reZYe4GKdJbRGrMD5NrGT1fUN6B3SJvxkNKPYnHd/Rwc5R0w9SYVOvXM
MWt5SSS4jAqfv/O59dbP0WO+4po1s1LEJFDsBcq4entyklnfiDTmA42FAepD6f0e
N1M0MSDqkP9qQALUxIEA8+9gFrp+hbRKgVashQiQz0dOFlikYrzUCf4kPFAcv0hJ
e9AvjrFQyfVV2T0+L1Nz9SHPqxTNNcxM2fkaWoOZ0GuPMeV67J3JZZS5fhw9ChYl
j6rnICXktsV5I+lG4A6q5maLWlmhwqaJhhxLMxCh+wwcn8AhG14FBYBnc5ylBeUG
1Add0PW/CUOtmG/FEh5Mt2Tg3rioMqArGJ9orlFF3ZyHs2CrkdxyUk/Lu7np19WJ
wMW93muuOyj1WkY5gfvB
=7XYH
-----END PGP SIGNATURE-----

--CnNpgxUS1mf00CB61sdS289nc1leVteEv--