[MathML4] Deprecation/Removal of the mfenced element

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--6elo9RkMhqDqIDIWHwntqU7uvtC5DkJjm
Content-Type: multipart/mixed; boundary="rsCvBCpf2o4w5T9SONJ8Ac7n4Pw4uu3MG"
From: =?UTF-8?B?RnLDqWTDqXJpYyBXQU5H?= <[email protected]>
To: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Subject: [MathML4] Deprecation/Removal of the mfenced element

--rsCvBCpf2o4w5T9SONJ8Ac7n4Pw4uu3MG
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi everybody,

Le 21/07/2016 =C3=A0 08:52, David Carlisle a =C3=A9crit :
> While it's true that the math WG is currently "on hold" as there were n=
o
> planned date to do a MathML4 to give implementations time to catch up
> with MathML3, this mailing list is still active and specific suggestion=
s
> can be posted here.

Assuming that David's response implies that the old Math WG is indeed
inclined to collaborate with Web engines developers and to take into
account feedback for a future MathML 4, we are going to start proposing
improvements on this mailing list.

One of the most serious design issue in the MathML specification is the
existence of the mfenced element. It is described as a "convenient form
in which to express common constructs involving fences" but is strictly
equivalent to an expanded form using mrow and mo elements [1]. So while
it may be helpful to the rare people writing MathML by hand it is a
redundant and poorly designed feature that has been the source of
troubles for implementers:

1) Implementers must ensure that all the cases listed on the MathML
specification are correctly handled to ensure perfect equivalence. This
has always been a source of complexity, errors, and code duplication. We
wrote a short list of tests covering the basic cases described in the
specification [2] and neither Gecko nor WebKit correctly handle all
these cases. And this list does not even take into account all the
features of operators (stretchiness, spacing etc). We found similar
inconsistencies/bugs in the past in WebKit accessibility code and/or
assistive technologies.

2) In the case of Web engines, you have to maintain the equivalence when
open/close/separators attributes or the list of children change. And
indeed, there are known bugs in WebKit related to dynamic modification
of mfenced.

3) In the case of WebKit, mfenced is implemented by creating anonymous
nodes for each operator and trying to keep them in sync with the DOM. In
the past, this kind of implementation has led to rendering, performance
and design/security issues. During phase 1 of our refactoring [3],
mfenced has caused many troubles and still has not been rewritten so
far. We could follow Gecko's implementation to get rid of these
anonymous nodes, at the price of more code duplication.

4) Phase 3 of our refactoring [3] now tries to move all parsing of
MathML attributes from renderer classes to DOM classes in order to
follow standard practice in WebKit's code base and improve
synchronization between the renderer and DOM classes. mfenced is causing
troubles because of its entanglement with the implementation of
operators. Again, it seems that addressing the design issue targeted by
phase 3 will lead to more code duplication if mfenced is kept.

5) The mfenced element is designed in a way that the text of fences and
separators is included in DOM attributes instead of DOM elements as it
is generally the case for text content. This means that by default (i.e.
unless some specific code is added to handle mfenced) it may not be
possible to search, select or copy that text using browser user
interfaces or to read the text using assistive technologies.

In order to simplify the code and make maintenance easier, we are going
to propose on WebKit & Mozilla mailing lists to remove support for the
mfenced element, maybe first to deprecate it. We also definitely do not
want to include support for the mfenced element in the MathML
implementation we have been working on for Blink.

The only other argument we heard in favor of the mfenced element was
that it gives "better semantic" to express fenced expressions with
opening/closing fences and separators. However, this is a
misunderstanding of the MathML specification: the semantic equivalence
is provided via the (perhaps implicit) fence & separator attributes on
the mo elements and via their relative positions inside the mrow containe=
r.

Also, note that "authors cannot be guaranteed that MathML preprocessors
won't replace occurrences of mfenced with equivalent expanded forms".
This means that even if equivalence may not be true for e.g. CSS style
or DOM manipulation it is anyway wrong to use CSS selectors or
Javascript code that make assumption on whether mfenced or its expanded
form is used.

Last but not least, the mfenced element is not used in the vast majority
of pages or authoring tools (Wikipedia, LibreOffice, latexml, itex2MML,
etc). [2] actually contains a simple Javascript function to do the
required mfenced expansion and hence keep some backward compatibility.

Fr=C3=A9d=C3=A9ric, for the Igalia Web Platform team

[1] https://www.w3.org/TR/MathML3/chapter3.html#presm.mfenced
[2] http://people.igalia.com/fwang/mfenced-polyfill/
[3] https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring



--rsCvBCpf2o4w5T9SONJ8Ac7n4Pw4uu3MG--

--6elo9RkMhqDqIDIWHwntqU7uvtC5DkJjm
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

iQIcBAEBCAAGBQJXljfrAAoJEL8nnpULUzQOhZ4P/AqB45DZiU9tQKd+61wKdl9h
fgvgAQDj2FzmrxJvGMJsynYJTjhe9B/xS7gRr276Jq8xNUQ8E8SMgGFBMAHjXlVU
ilKy0Thxva+XkRaBHOyqEihlAxP8hiQhtNwQhO37a5j9340EDi8BZbojlXCyGn2O
s7W3QpZwt5XManbQP4S/uYH54mCa2dcXZAyeq9EuqEaTdh+aNOYDO/c9rumVHIOa
vl/unQY7dHTjG7+KDT2+8dbWhAKjcGbWtlAd/kuaA7F1K+yoFnuY7QtKoVehhuE+
Vd2r45ERJNBdO5IuE0vwNH28DgkeqiaA0arpaAdoAUUM9hjA4s4tQIV7aZgV5nI0
jwRt4tcG4kUNbIkkPRBKtncAl6Uxt2L9S9j79p28QDtABfBfSuWQ+gJ1/1oVHtMc
KJ16BAJ4KH8peClMA2t2UzQnOooQrpWCa/8w0NEe6hs/aLuTEmoOgBKlManzCKON
o5u3Oziv2m882U0tjHWy7SHgXUxbqEJkqnf5/JkRJnZxVX6peG7SfwrcoCWazG0y
Cu764pYfYN3LTbs+Z9To4cwSLZFhVs6f1t1NWaeES8LWYhPlxScyPRK2pepwkCl3
C0vB68s7Om1PeJrUSlV0w2h6nltSi/rFXwYBVqBJXJmUZ5kZOyZnhlCExB0Q6ZyF
+a41dxuSJmbjAKrUnYE6
=UxGM
-----END PGP SIGNATURE-----

--6elo9RkMhqDqIDIWHwntqU7uvtC5DkJjm--