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

Hi All,

Just as a data point in this discussion. In Mathematica we canonicalize =
on using <mrow> and <mo>. (I standardized on this when I added the =
implementation.)

That is if you roundtrip via: MathML -> Mathematica -> MathML the =
<mfenced>s will be rewritten into the equivalent <mrow> and <mo> =
operators.

(And, also I should note: we of course maintain proper grouping of the =
<mrow>s. It is fundamental to our typesetting system.)

Cheers,
     Jason=20

> On Jul 25, 2016, at 6:01 PM, Fr=C3=A9d=C3=A9ric WANG =
<[email protected]> wrote:
>=20
> Hi everybody,
>=20
> 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 =
no
>> planned date to do a MathML4 to give implementations time to catch up
>> with MathML3, this mailing list is still active and specific =
suggestions
>> can be posted here.
>=20
> 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.
>=20
> 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:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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 =
container.
>=20
> 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.
>=20
> 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.
>=20
> Fr=C3=A9d=C3=A9ric, for the Igalia Web Platform team
>=20
> [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
>=20
>=20