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

--001a114d87a4265fa705387ce869
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=A9d=C3=A9ric WANG <[email protected]=
r> wrote:

> Hi everybody,
>
> 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 n=
o
> > planned date to do a MathML4 to give implementations time to catch up
> > with MathML3, this mailing list is still active and specific suggestion=
s
> > 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 containe=
r.
>
> 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=C3=A9d=C3=A9ric, 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
>
>
>

--001a114d87a4265fa705387ce869
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I see your point, but have to say that I am not really sat=
isfied with the current spec language regarding equivalence. =C2=A0 =C2=A0 =
Mfenced can also give information about grouping that is lost with the mrow=
 formulation, e.g. an mrow containining [a, b [ f ] d, e] =C2=A0 may be a l=
ist of three things or a pair of half open intervals with an f in the middl=
e.<div><br></div><div>Stephen</div></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Mon, Jul 25, 2016 at 12:01 PM, Fr=C3=A9d=C3=A9ri=
c WANG <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D=
"_blank">[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">Hi everybody,<br>
<br>
Le 21/07/2016 =C3=A0 08:52, David Carlisle a =C3=A9crit :<br>
&gt; While it&#39;s true that the math WG is currently &quot;on hold&quot; =
as there were no<br>
&gt; planned date to do a MathML4 to give implementations time to catch up<=
br>
&gt; with MathML3, this mailing list is still active and specific suggestio=
ns<br>
&gt; can be posted here.<br>
<br>
Assuming that David&#39;s response implies that the old Math WG is indeed<b=
r>
inclined to collaborate with Web engines developers and to take into<br>
account feedback for a future MathML 4, we are going to start proposing<br>
improvements on this mailing list.<br>
<br>
One of the most serious design issue in the MathML specification is the<br>
existence of the mfenced element. It is described as a &quot;convenient for=
m<br>
in which to express common constructs involving fences&quot; but is strictl=
y<br>
equivalent to an expanded form using mrow and mo elements [1]. So while<br>
it may be helpful to the rare people writing MathML by hand it is a<br>
redundant and poorly designed feature that has been the source of<br>
troubles for implementers:<br>
<br>
1) Implementers must ensure that all the cases listed on the MathML<br>
specification are correctly handled to ensure perfect equivalence. This<br>
has always been a source of complexity, errors, and code duplication. We<br=
>
wrote a short list of tests covering the basic cases described in the<br>
specification [2] and neither Gecko nor WebKit correctly handle all<br>
these cases. And this list does not even take into account all the<br>
features of operators (stretchiness, spacing etc). We found similar<br>
inconsistencies/bugs in the past in WebKit accessibility code and/or<br>
assistive technologies.<br>
<br>
2) In the case of Web engines, you have to maintain the equivalence when<br=
>
open/close/separators attributes or the list of children change. And<br>
indeed, there are known bugs in WebKit related to dynamic modification<br>
of mfenced.<br>
<br>
3) In the case of WebKit, mfenced is implemented by creating anonymous<br>
nodes for each operator and trying to keep them in sync with the DOM. In<br=
>
the past, this kind of implementation has led to rendering, performance<br>
and design/security issues. During phase 1 of our refactoring [3],<br>
mfenced has caused many troubles and still has not been rewritten so<br>
far. We could follow Gecko&#39;s implementation to get rid of these<br>
anonymous nodes, at the price of more code duplication.<br>
<br>
4) Phase 3 of our refactoring [3] now tries to move all parsing of<br>
MathML attributes from renderer classes to DOM classes in order to<br>
follow standard practice in WebKit&#39;s code base and improve<br>
synchronization between the renderer and DOM classes. mfenced is causing<br=
>
troubles because of its entanglement with the implementation of<br>
operators. Again, it seems that addressing the design issue targeted by<br>
phase 3 will lead to more code duplication if mfenced is kept.<br>
<br>
5) The mfenced element is designed in a way that the text of fences and<br>
separators is included in DOM attributes instead of DOM elements as it<br>
is generally the case for text content. This means that by default (i.e.<br=
>
unless some specific code is added to handle mfenced) it may not be<br>
possible to search, select or copy that text using browser user<br>
interfaces or to read the text using assistive technologies.<br>
<br>
In order to simplify the code and make maintenance easier, we are going<br>
to propose on WebKit &amp; Mozilla mailing lists to remove support for the<=
br>
mfenced element, maybe first to deprecate it. We also definitely do not<br>
want to include support for the mfenced element in the MathML<br>
implementation we have been working on for Blink.<br>
<br>
The only other argument we heard in favor of the mfenced element was<br>
that it gives &quot;better semantic&quot; to express fenced expressions wit=
h<br>
opening/closing fences and separators. However, this is a<br>
misunderstanding of the MathML specification: the semantic equivalence<br>
is provided via the (perhaps implicit) fence &amp; separator attributes on<=
br>
the mo elements and via their relative positions inside the mrow container.=
<br>
<br>
Also, note that &quot;authors cannot be guaranteed that MathML preprocessor=
s<br>
won&#39;t replace occurrences of mfenced with equivalent expanded forms&quo=
t;.<br>
This means that even if equivalence may not be true for e.g. CSS style<br>
or DOM manipulation it is anyway wrong to use CSS selectors or<br>
Javascript code that make assumption on whether mfenced or its expanded<br>
form is used.<br>
<br>
Last but not least, the mfenced element is not used in the vast majority<br=
>
of pages or authoring tools (Wikipedia, LibreOffice, latexml, itex2MML,<br>
etc). [2] actually contains a simple Javascript function to do the<br>
required mfenced expansion and hence keep some backward compatibility.<br>
<br>
Fr=C3=A9d=C3=A9ric, for the Igalia Web Platform team<br>
<br>
[1] <a href=3D"https://www.w3.org/TR/MathML3/chapter3.html#presm.mfenced" r=
el=3D"noreferrer" target=3D"_blank">https://www.w3.org/TR/MathML3/chapter3.=
html#presm.mfenced</a><br>
[2] <a href=3D"http://people.igalia.com/fwang/mfenced-polyfill/" rel=3D"nor=
eferrer" target=3D"_blank">http://people.igalia.com/fwang/mfenced-polyfill/=
</a><br>
[3] <a href=3D"https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring" =
rel=3D"noreferrer" target=3D"_blank">https://trac.webkit.org/wiki/MathML/Ea=
rly_2016_Refactoring</a><br>
<br>
<br>
</blockquote></div><br></div>

--001a114d87a4265fa705387ce869--