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