Removal/Deprecation of <mfenced>

[fred-wang]

This proposal is to remove the <mfenced> element or at least deprecate it.

From the Math WG: https://lists.w3.org/Archives/Public/www-math/2016Jul/0004.html
From the original "MathML in HTML5" appendix: "The element is just a “convenient form in which to express common constructs involving fences” but is strictly equivalent to an expanded form with and elements and has many exceptions to handle. It is thus not actually necessary and just requires more code for implementers and may lead to rendering inconsistencies with the expanded form. It requires web rendering engines to create many “anonymous” rendering frames (or similar) and keep them up-to-date which may lead to rendering, performance or security issues. Because the text of fences and separators is included in attributes and not in MathML elements then by default it may not be possible to search, select, copy it. It may also not be exposed to assitive technologies without further effort. In this document support for mfenced is not required. Authors are encouraged to use the expanded form and we recommend that the element is dropped from future version of the MathML specification. "

[fred-wang]

mfenced is currently not defined in MathML Core, so this is just for mathml4

[dani31415]

There is a precedent of content in an attribute that is selectable and exposed to the AT: the value attribute of the input HTML tag.

[physikerwelt]

discussed in the telco on 2019-02-25:

• no consensus. Murray points out the semantics advantages of mfenced.

[fred-wang]

Polyfill has been moved to:
https://mathml-refresh.github.io/mathml-polyfills/mfenced/
https://github.com/mathml-refresh/mathml-polyfills/tree/master/mfenced

[NSoiffer]

Based on the stats we have, mfenced is not used by converters. NAG uses it extensively, but the MathML spec defines its equivalence and so it doesn't add functionality. Given it's use, it would be wrong to deprecate from the full spec, but given it's equivalence, I don't see a need to keep it in core.

[fred-wang]

Resolution:
Notes are not published yet but we agree to remove from core and keep in full?

Specification:
MathML Full probably needs update.

Implementation:
Need to remove from WebKit and Firefox.
No plan to implement it in Chromium.

Polyfill:
We have polyfills with manual tests at https://github.com/mathml-refresh/mathml-polyfills/tree/master/mfenced
As @bkardell pointed out we probably need to decide how we want our polyfill to look like to remain compatible with the rest of the web platform. Also we might other things like nodejs converters that can be embedded in MathML generators' pipeline. Anyway, probably a separate discussion.
I'm keeping "need polyfill" for the record.

Tests:

• Check that mfenced is not supported.

[fred-wang]

(I added need resolution, until the notes are published and someone link them from here)

[fred-wang]

Consensus: remove from core and keep in full

[fred-wang]

@davidcarlisle I removed the mention of mfenced from the intro (also checked it's not in the relaxng schema). I'm leaving the "spec update" label set until you review what has to be done for full.

[fred-wang]

Before writing a test for that, we would need to know how to handle unknown MathML elements. See #139

[fred-wang]

The alternative would be to do like maction ( #26 ) and keep it in core as mrow-like.

[fred-wang]

Test added so closing.

[Yaffle]

Because the text of fences and separators is included in attributes and not in MathML elements then by default it may not be possible to search, select, copy it

Hello!
By the way, the same is true for the surd of <msqrt> and <mroot> today.