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

Indeed, but the appropriately grouped structure could be represented with mrow, as well as mfenced.  Likewise, the inappropriately grouped structure can be represented with mfenced.

bruce

________________________________________
From: Stephen Watt <smwatt@gmail.com>
Sent: Monday, July 25, 2016 6:00:04 PM
To: Frédéric WANG
Cc: www-math@w3.org
Subject: Re: [MathML4] Deprecation/Removal of the mfenced element

I see your point, but have to say that I am not really satisfied with the current spec language regarding equivalence.     Mfenced can also give information about grouping that is lost with the mrow formulation, e.g. an mrow containining [a, b [ f ] d, e]   may be a list of three things or a pair of half open intervals with an f in the middle.

Stephen

On Mon, Jul 25, 2016 at 12:01 PM, Frédéric WANG <fred.wang@free.fr<mailto:fred.wang@free.fr>> wrote:
Hi everybody,

Le 21/07/2016 à 08:52, David Carlisle a écrit :
> 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.

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 container.

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édéric, 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

Received on Tuesday, 26 July 2016 08:46:52 UTC