<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - [meta] Removing/rewriting the mfenced implementation"
href="https://bugs.webkit.org/show_bug.cgi?id=160509">160509</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[meta] Removing/rewriting the mfenced implementation
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>Product</th>
<td>WebKit
</td>
</tr>
<tr>
<th>Version</th>
<td>WebKit Nightly Build
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>URL</th>
<td>https://www.w3.org/TR/MathML3/chapter3.html#presm.mfenced
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>Normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P2
</td>
</tr>
<tr>
<th>Component</th>
<td>MathML
</td>
</tr>
<tr>
<th>Assignee</th>
<td>webkit-unassigned@lists.webkit.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>fred.wang@free.fr
</td>
</tr>
<tr>
<th>CC</th>
<td>alex@igalia.com, bfulgham@webkit.org, cfleizach@apple.com, darin@apple.com, jdiggs@igalia.com, jfernandez@igalia.com, rego@igalia.com
</td>
</tr>
<tr>
<th>Depends on</th>
<td>57696, 125938, 139436, 160396, 160507
</td>
</tr></table>
<p>
<div>
<pre>One of the most serious design issue in the MathML specification is the existence of the mfenced element:
* It is strictly equivalent to an expanded form using the mrow and mo elements. There are several complicate equivalence rules to handle and WebKit (or any other implementations) does not support them completely. As a consequence this adds duplicate logic and code to our MathML implementation to support something that does not bring anything new for math rendering or accessibility.
* The text in mfenced is contained in the attributes rather than in text nodes. This makes mfenced quite different from the rest of the platform and sharing code even more difficult. This is also the cause of many other bugs or the need for special handling (see below).
Issues with this element have been reported to the W3C for a long time but it seems to have been a controversial topic in the Math WG mailing list from its beginning. The last thread is <a href="https://lists.w3.org/Archives/Public/www-math/2016Jul/0004.html">https://lists.w3.org/Archives/Public/www-math/2016Jul/0004.html</a> but it seems unlikely that the Math WG will address this anytime soon.
The mfenced element is not used in the vast majority of pages or authoring tools (Wikipedia, LibreOffice, latexml, itex2MML, etc). I personally believe the best would just be to remove support for that element in order to clean up our code (Mozilla could do the same in Gecko and other web engines do not support it anyway). If it turned out to be used in old pages then backward compatibility can be ensured by this simple polyfill: <a href="https://people.igalia.com/fwang/mfenced-polyfill/mfenced.js">https://people.igalia.com/fwang/mfenced-polyfill/mfenced.js</a>
If we decide to keep it then it will definitely have to be rewritten completely. Here is a non-exhaustive list of issues in WebKit's implementation:
I) We do not handle the edge case of empty <mfenced> correctly. This is test 1 of <a href="https://people.igalia.com/fwang/mfenced-polyfill/">https://people.igalia.com/fwang/mfenced-polyfill/</a>
II) The MathML specification is not clear about whether open and close fences can have multiple characters but we removed support for this edge case in r202271. This is test 10 of <a href="https://people.igalia.com/fwang/mfenced-polyfill/">https://people.igalia.com/fwang/mfenced-polyfill/</a>. open and close fences are still stored on the RenderMathMLFenced class as string. Probably this can just become UChar32 and does not need to be stored on the class.
III) Similarly, the parsing of the separators attribute can probably be made more efficient and we may not need to store m_separators on the RenderMathMLFenced class. See also <a class="bz_bug_link
bz_status_NEW "
title="NEW - improve how mfenced@separators is handled"
href="show_bug.cgi?id=125938">bug 125938</a>.
IV) We do not handle surrogate pairs in attributes correctly. This is test 15 of <a href="https://people.igalia.com/fwang/mfenced-polyfill/">https://people.igalia.com/fwang/mfenced-polyfill/</a>. See also <a class="bz_bug_link
bz_status_NEW "
title="NEW - improve how mfenced@separators is handled"
href="show_bug.cgi?id=125938">bug 125938</a>.
V) RenderMathMLFenced is not updated properly when attributes are modified. See <a class="bz_bug_link
bz_status_NEW "
title="NEW - mfenced element fails to update dynamically when its open, close and separators attributes are changed"
href="show_bug.cgi?id=57696">bug 57696</a> and <a href="https://bug-57696-attachments.webkit.org/attachment.cgi?id=285222">https://bug-57696-attachments.webkit.org/attachment.cgi?id=285222</a>.
VI) RenderMathMLFenced is not updated properly when the child list is modified. See <a class="bz_bug_link
bz_status_NEW "
title="NEW - The mfenced element does no update correctly when its child list is changed"
href="show_bug.cgi?id=160507">bug 160507</a> and <a href="https://bug-160507-attachments.webkit.org/attachment.cgi?id=285227">https://bug-160507-attachments.webkit.org/attachment.cgi?id=285227</a>.
VII) Because the text of operators is in attributes they are not searchable/selectable by default. See <a class="bz_bug_link
bz_status_NEW "
title="NEW - mfenced operators are not searchable/selectable"
href="show_bug.cgi?id=139436">bug 139436</a>.
VIII) We use of the old RenderPtr object to hold anonymous operators. See <a class="bz_bug_link
bz_status_NEW "
title="NEW - Use std::unique_ptr for mfenced anonymous operators"
href="show_bug.cgi?id=160396">bug 160396</a>.
IX) The anonymous operators need special handling to work the same as "normal" operators causing additional maintenance cost. This has been quite painful to handle during code refactoring. However, the code for anonymous operators is now better isolated (RenderMathMLFencedOperator.cpp and m_isAnonymousOperator=true in AccessibilityMathMLElement.cpp).
Some of the issues above could be fixed by applying the same refactoring as for other MathML classes:
1) Do not create anonymous nodes. This was done for other element in <a href="https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring#Phase1">https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring#Phase1</a>
2) Move attribute parsing from RenderMathMLFenced class to DOM classes. This was done for other elements in <a href="https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring#Phase3">https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring#Phase3</a>
One of the issue with 1) is that the accessibility code assumes the presence of these anonymous operators in the render tree and so removing them without modifying the accessible tree will be tricky.
A third option is of course to keep the status quo of mfenced will all its bugs and design issues and hope that it will now no longer interfere too much with the rest of the code.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>