[MathML4] Deprecation/Removal of the mfenced element

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[MathML4] Deprecation/Removal of the mfenced element

Frédéric WANG
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



signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Murray Sargent

Hmm. I like <mfenced>. It's an element that says up front what it means. <mrow> is abstract and requires parsing before you know what it means. In Microsoft Office math, there is the "delimiters" element <d> that maps neatly into <mfenced>. The LineServices math handler formats such elements automatically expanding to fit their arguments. The result is math typography very much like TeX, but without the need for control words like \biggl.

 

Our products can generate and input MathML using <mrow> instead of <mfenced>, but parsing similar to that used for the math linear format is used to convert to <d>.

 

Murray

 

 

Reply | Threaded
Open this post in threaded view
|

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

Stephen Watt-3
In reply to this post by Frédéric WANG
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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Frédéric WANG
In reply to this post by Murray Sargent
Le 25/07/2016 à 20:39, Murray Sargent a écrit :

Hmm. I like <mfenced>. It's an element that says up front what it means. <mrow> is abstract and requires parsing before you know what it means. In Microsoft Office math, there is the "delimiters" element <d> that maps neatly into <mfenced>. The LineServices math handler formats such elements automatically expanding to fit their arguments. The result is math typography very much like TeX, but without the need for control words like \biggl.

 

Our products can generate and input MathML using <mrow> instead of <mfenced>, but parsing similar to that used for the math linear format is used to convert to <d>.


As I see, this is an internal implementation details for the Microsoft Word / LineServices that does not need to be exposed to the Web or handled everywhere. You already have import/export features between MathML to OfficeMath including between <mrow>/<mo> and <d> so I don't see how it helps to have an <mfenced> element when you have to handle the general case anyway.

MathML is centered around mrow and mo elements with a dictionary of properties. Whether or not it is a good idea is a separate discussion, but it's a core feature of MathML and is unlikely to be changed in the future. That implies that you must implement these general cases anyway and so mfenced or Office's n-ary elements are duplicate features that do not bring anything new but pain for implementers.

I would really be curious to hear progress from the Edge developers regarding the implementation of MathML. I'm dubious that the design of mfenced (renderer text provided in attributes, parsing needed to expand the element, duplicate of mrow+mo) make them happy.
-- 
Frédéric Wang

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Frédéric WANG
In reply to this post by Stephen Watt-3
Le 26/07/2016 à 00:00, Stephen Watt a écrit :
> 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.
So the only thing you are saying is that expanding to plain text without
explicit grouping implies loss of information compared to using mfenced.
That's true, but that's not my point. If you really follow the expansion
rules in MathML3 instead of using plain text then you see that nothing
is lost in your example and that the mfenced element is again useless.

Certainly, one can write <mo>+<mrow> without proper grouping as that's
unfortunately often the case for markup generated from text
representation like TeX or ASCII. But the existence of an mfenced
element in MathML does not magically force converters or people to do
this grouping.



signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

David Carlisle
On 26/07/2016 08:09, Frédéric WANG wrote:
> Certainly, one can write <mo>+<mrow> without proper grouping as that's
> unfortunately often the case for markup generated from text
> representation like TeX or ASCII. But the existence of an mfenced
> element in MathML does not magically force converters or people to do
> this grouping.

Yes I agree with Frédéric here that as long as you put all the mrow back
in, there is no loss of information in expanding out mfenced.

Speaking personally, for this and for the msqrt suggestion (and I
suspect others to follow:-) I don't really have a problem if as a
browser rendering environment we end up specifying some more minimalist
profile of MathML that provides all the rendering functionality needed
with less duplication in the markup possibilities.

People who are generating mathml and want the markup to closely follow
the underlying dom and rendering trees (perhaps to ease interactive
behaviour such as selecting subterms) would want to stick to that profile.

People wanting to generate (or render existing) MathML 2 and 3 style
markup could be provided with a very lightweight javascript that expands
out mfenced and does whatever else is needed. This means that
mfenced<->mrow/mo equivalence is moved out of the core rendering engines
into user javascript space which, if it helps get mathml into the core
rendering engines, isn't too high a price to pay, I think.

Such a javascript would be at the same level as the original asciimathml
  javascript for example, something that takes a specified user input
syntax and modifies the DOM to the mathml elements supported on the
platform. (The same can of course be done with content mathml)
which means that these aspects are not browser specific and the same
transformation code can be used across browsers, and just used at the
option of the page author if they reference the appropriate code.

David

________________________________


The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.



This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________

Reply | Threaded
Open this post in threaded view
|

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

Bruce R Miller
In reply to this post by Stephen Watt-3
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 <[hidden email]>
Sent: Monday, July 25, 2016 6:00:04 PM
To: Frédéric WANG
Cc: [hidden email]
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 <[hidden email]<mailto:[hidden email]>> 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




Reply | Threaded
Open this post in threaded view
|

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

Stephen Watt-3
In reply to this post by Frédéric WANG
Sorry, no.   I did not mean expanding to plain text.   

I meant the leaf elements would be tagged.   So the example is 

<mrow> <mo>[</mo> <mi>a</mi> <mo>,</mo>  <mi>b</mi>
<mo>[</mo> <mi>f</mi> <mo>]</mo> <mi>d</mi> <mo>,</mo>
<mi>e</mi> <mo>]</mo> </mrow>

 or "an mrow containing [a, b [ f ] d, e]"  for easier discussion.

I almost agree with you and David that if you put in all the mrows (by hand or by code generation) then there is no information loss between an mfenced and a 3 element mrow.   

We would have to require that syntactically paired operators be given as the first and last elements of a three element mrow.    But do we ALWAYS want three element mrows with first and last elements being operators to be treated as mfenced is?  What about [ x )  or [ + ] or, my personal favourite,   - x ! 

Secondly, can we really rely on all mathml  to put in all the grouping mrows?    We don't require it so I don't think we can count on it.  

We also have to allow for fence separators that stretch such as  < x | Q | y > or  ( a | b ).  In the <x | Q | y> example, we would want the bars to stretch in the quantum mechanical case, but not if we were talking about the expected value of x times the absolute value of Q times y.     So we would have to have

<mrow> \langle x | Q | y \rangle </mrow>  vs
 <mrow> \langle  <mrow> x  <mrow> | Q |</mrow> y </mrow> \rangle </mrow>   

where \langle and \rangle mean the relevant unicode points and leaf tagging is implied.

What is the rule?   An <mrow> with the first and last elements being operators all middle operators taken as separators?   This works for  < x | Q | y >  but not for -x - y + 3!

How would you handle these cases?

Stephen



On Tue, Jul 26, 2016 at 3:09 AM, Frédéric WANG <[hidden email]> wrote:
Le 26/07/2016 à 00:00, Stephen Watt a écrit :
> 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.
So the only thing you are saying is that expanding to plain text without
explicit grouping implies loss of information compared to using mfenced.
That's true, but that's not my point. If you really follow the expansion
rules in MathML3 instead of using plain text then you see that nothing
is lost in your example and that the mfenced element is again useless.

Certainly, one can write <mo>+<mrow> without proper grouping as that's
unfortunately often the case for markup generated from text
representation like TeX or ASCII. But the existence of an mfenced
element in MathML does not magically force converters or people to do
this grouping.



Reply | Threaded
Open this post in threaded view
|

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

Frédéric WANG
Le 26/07/2016 à 14:49, Stephen Watt a écrit :
But do we ALWAYS want three element mrows with first and last elements being operators to be treated as mfenced is?
No, we just follow the equivalence given in the specification with mrow & mo elements and separator & fence attributes (whose default value is given in the operator dictionary). If you don't want to obtain this interpretation, then you can change the grouping or use explicit attributes to override the operator dictionary).
Secondly, can we really rely on all mathml  to put in all the grouping mrows?    We don't require it so I don't think we can count on it. 
This is a separate issue. As I said, the existence of an mfenced element won't make people or tools magically do proper grouping. So if we don't remove the whole <mrow>+<mo> stuff then mfenced is useless.

We also have to allow for fence separators that stretch such as  < x | Q | y > or  ( a | b ).  In the <x | Q | y> example, we would want the bars to stretch in the quantum mechanical case, but not if we were talking about the expected value of x times the absolute value of Q times y.     So we would have to have

<mrow> \langle x | Q | y \rangle </mrow>  vs
 <mrow> \langle  <mrow> x  <mrow> | Q |</mrow> y </mrow> \rangle </mrow>   

where \langle and \rangle mean the relevant unicode points and leaf tagging is implied.

What is the rule?   An <mrow> with the first and last elements being operators all middle operators taken as separators?   This works for  < x | Q | y >  but not for -x - y + 3!
Not sure I understand all of these. Again, we have the separator properties in the operator dictionary whose default value we can override via an explicit attribute. The stretchiness is controlled by the strechy property, which is also given from the operator dictionary or an explicit attribute. But actually your comment exhibit another issue with mfenced I forgot to mention: you can not override the default properties of its operators. On the other hand <mo> gives more flexbility.

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Bruce R Miller
In reply to this post by Stephen Watt-3
I really just meant that either of the grouping structures (bra-ket and mean value of an absolute value) could be represented with mrow.  And that I wouldn't necessarily trust an author (or generator) to use the markup choices that you find most meaningful, or that it means what you'd want to assume it is.  They could also write -x! using mfenced.

________________________________________
From: Stephen Watt <[hidden email]>
Sent: Tuesday, July 26, 2016 8:49:04 AM
To: Frédéric WANG
Cc: [hidden email]
Subject: Re: [MathML4] Deprecation/Removal of the mfenced element

Sorry, no.   I did not mean expanding to plain text.

I meant the leaf elements would be tagged.   So the example is

<mrow> <mo>[</mo> <mi>a</mi> <mo>,</mo>  <mi>b</mi>
<mo>[</mo> <mi>f</mi> <mo>]</mo> <mi>d</mi> <mo>,</mo>
<mi>e</mi> <mo>]</mo> </mrow>

 or "an mrow containing [a, b [ f ] d, e]"  for easier discussion.

I almost agree with you and David that if you put in all the mrows (by hand or by code generation) then there is no information loss between an mfenced and a 3 element mrow.

We would have to require that syntactically paired operators be given as the first and last elements of a three element mrow.    But do we ALWAYS want three element mrows with first and last elements being operators to be treated as mfenced is?  What about [ x )  or [ + ] or, my personal favourite,   - x !

Secondly, can we really rely on all mathml  to put in all the grouping mrows?    We don't require it so I don't think we can count on it.

We also have to allow for fence separators that stretch such as  < x | Q | y > or  ( a | b ).  In the <x | Q | y> example, we would want the bars to stretch in the quantum mechanical case, but not if we were talking about the expected value of x times the absolute value of Q times y.     So we would have to have

<mrow> \langle x | Q | y \rangle </mrow>  vs
 <mrow> \langle  <mrow> x  <mrow> | Q |</mrow> y </mrow> \rangle </mrow>

where \langle and \rangle mean the relevant unicode points and leaf tagging is implied.

What is the rule?   An <mrow> with the first and last elements being operators all middle operators taken as separators?   This works for  < x | Q | y >  but not for -x - y + 3!

How would you handle these cases?

Stephen



On Tue, Jul 26, 2016 at 3:09 AM, Frédéric WANG <[hidden email]<mailto:[hidden email]>> wrote:
Le 26/07/2016 à 00:00, Stephen Watt a écrit :
> 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.
So the only thing you are saying is that expanding to plain text without
explicit grouping implies loss of information compared to using mfenced.
That's true, but that's not my point. If you really follow the expansion
rules in MathML3 instead of using plain text then you see that nothing
is lost in your example and that the mfenced element is again useless.

Certainly, one can write <mo>+<mrow> without proper grouping as that's
unfortunately often the case for markup generated from text
representation like TeX or ASCII. But the existence of an mfenced
element in MathML does not magically force converters or people to do
this grouping.




Reply | Threaded
Open this post in threaded view
|

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

Jason Harris
In reply to this post by Frédéric WANG
Hi All,

Just as a data point in this discussion. In Mathematica we canonicalize on using <mrow> and <mo>. (I standardized on this when I added the implementation.)

That is if you roundtrip via: MathML -> Mathematica -> MathML the <mfenced>s will be rewritten into the equivalent <mrow> and <mo> operators.

(And, also I should note: we of course maintain proper grouping of the <mrow>s. It is fundamental to our typesetting system.)

Cheers,
     Jason

> On Jul 25, 2016, at 6:01 PM, Frédéric WANG <[hidden email]> 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
>
>



Reply | Threaded
Open this post in threaded view
|

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

William F Hammond
In reply to this post by Stephen Watt-3

I have always liked "mfenced".

I think it is useful in catching translations from
well-designed LaTeX profiles.

I think it is useful to preserve as much semantic
information as might be reasonably found, or at least
derived by standard inference, in a well-designed LaTeX
profile.  Toward this end I think it will be good to be able
to continue making a distinction between the two concepts
that might in a computer algebra system be called
"expression sequence", on the one hand, and "list", on the
other.

I have always argued against the strict equivalence.  Less
harm would be done simply by relaxing that lousy standard
than by pulling mfenced.  I have mostly kept quiet my
complaints about processing decisions in the MathML world,
e.g., <mo>, based on CDATA values, in effect, using CDATA as
SDATA.  Really, such practice breaks the paradigm of XML.
In many cases my response to the loss of SDATA is to provide
empty, sometimes defined-empty elements, to replace what
might otherwise have been SDATA.  The gain with this is that
element content may contain markup whereas attribute values
may not.

In that direction another approach would be to deprecate the
"open", "close", and "separators" attributes in favor of new
elements that replace them.  That is, provide an mfenced
head, e.g., <mfhead>, and provide empty-element names for
things allowed as openers, closers, and separators, which are
allowed as children of <mfhead>.  The members of the list
could then be simply the children of <mfenced> that follow
<mfhead>, with the presence of <mfhead>.

I will read more carefully through FW's long list of
processing concerns in a few weeks.

In the end, the design of an XML markup is about the
organization of processing.  This requires time for thought
and experimentation.

                                    -- Bill


Reply | Threaded
Open this post in threaded view
|

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

Daniel Marques-6
I also like the "mfenced". Vertical stretchies with <mo> are difficult to
understand from the point of view of someone who uses a formula editor.
What people understands when editing is that an open and close parenthesis
grows according to what's inside. Thus, for people who do editors, the
preferred feature is the mfenced.

There is also a VERY important aspect which is BACKWARD COMPATIBILITY.
There are plenty of formulas that use mfenced. Both Microsoft Word and
WIRIS (I'm not able to test MathType at this moment) use the mfenced tag
for stretchy parenthesis.

Losing backward compatibility will result that a lot of formulas stop
working. This would yield a lack of trust on the MathML specification.
Please do not commit that mistake!

Dani



-----Original Message-----
From: William F Hammond [mailto:[hidden email]] On Behalf Of William
F Hammond
Sent: martes, 26 de julio de 2016 20:09
To: [hidden email]
Subject: Re: [MathML4] Deprecation/Removal of the mfenced element


I have always liked "mfenced".

I think it is useful in catching translations from well-designed LaTeX
profiles.

I think it is useful to preserve as much semantic information as might be
reasonably found, or at least derived by standard inference, in a
well-designed LaTeX profile.  Toward this end I think it will be good to
be able to continue making a distinction between the two concepts that
might in a computer algebra system be called "expression sequence", on the
one hand, and "list", on the other.

I have always argued against the strict equivalence.  Less harm would be
done simply by relaxing that lousy standard than by pulling mfenced.  I
have mostly kept quiet my complaints about processing decisions in the
MathML world, e.g., <mo>, based on CDATA values, in effect, using CDATA as
SDATA.  Really, such practice breaks the paradigm of XML.
In many cases my response to the loss of SDATA is to provide empty,
sometimes defined-empty elements, to replace what might otherwise have
been SDATA.  The gain with this is that element content may contain markup
whereas attribute values may not.

In that direction another approach would be to deprecate the "open",
"close", and "separators" attributes in favor of new elements that replace
them.  That is, provide an mfenced head, e.g., <mfhead>, and provide
empty-element names for things allowed as openers, closers, and
separators, which are allowed as children of <mfhead>.  The members of the
list could then be simply the children of <mfenced> that follow <mfhead>,
with the presence of <mfhead>.

I will read more carefully through FW's long list of processing concerns
in a few weeks.

In the end, the design of an XML markup is about the organization of
processing.  This requires time for thought and experimentation.

                                    -- Bill

Reply | Threaded
Open this post in threaded view
|

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

David Carlisle
On 26/07/2016 20:11, Daniel Marques wrote:

> I also like the "mfenced". Vertical stretchies with <mo> are difficult to
> understand from the point of view of someone who uses a formula editor.
> What people understands when editing is that an open and close parenthesis
> grows according to what's inside. Thus, for people who do editors, the
> preferred feature is the mfenced.
>
> There is also a VERY important aspect which is BACKWARD COMPATIBILITY.
> There are plenty of formulas that use mfenced. Both Microsoft Word and
> WIRIS (I'm not able to test MathType at this moment) use the mfenced tag
> for stretchy parenthesis.
>
> Losing backward compatibility will result that a lot of formulas stop
> working. This would yield a lack of trust on the MathML specification.
> Please do not commit that mistake!
>
> Dani
>
>

I don't think we should remove (or even deprecate) anything but if there
are features that can be omitted from a profile that makes it easier to
get mathml into browsers I'm certainly open to discuss that.

especially cases that could easily be polyfilled with some lightweight
javascript as for mfenced->mrow conversion.

If the alternative is not a "full" mathml3 implementation but rather no
native implementation at all, and having to implement the entire
rendering in javacript then some subset profile should I think be
considered even if it complicates the story on compatibility.

I think the question is what's the minimum that need to be added to a
browser's core rendering code that enables a useful subset of mathml to
be rendered directly and the rest via some (relatively) simple
javascript support.

Anyway I encourage Frédéric to keep posting suggestions, certainly
there's no rush to standardise anything at this stage, but keeping track
of what works in practice across webkit and gecko (and hopefully one day
blink and edge) and specifying that at some point, even if that is a
subset of "full" mathml would I think be a useful exercise.

David




________________________________


The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.



This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________

Reply | Threaded
Open this post in threaded view
|

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

Frédéric WANG
In reply to this post by Daniel Marques-6
Le 26/07/2016 à 21:11, Daniel Marques a écrit :
I also like the "mfenced". Vertical stretchies with <mo> are difficult to
understand from the point of view of someone who uses a formula editor.
What people understands when editing is that an open and close parenthesis
grows according to what's inside. Thus, for people who do editors, the
preferred feature is the mfenced.
You can definitely use mfenced internally in a formula editor if that improves the UI. However, if that editor is not able to import/export from and to the canonical form described in the MathML recommendation then that's definitely a big flaw in that product.

There is also a VERY important aspect which is BACKWARD COMPATIBILITY.
There are plenty of formulas that use mfenced. Both Microsoft Word and
WIRIS (I'm not able to test MathType at this moment) use the mfenced tag
for stretchy parenthesis.

Losing backward compatibility will result that a lot of formulas stop
working. This would yield a lack of trust on the MathML specification.
Please do not commit that mistake!
MathML is not implemented in Edge or Blink, so we currently have to use converters to other formats in order to display formulas in all web rendering engines. Having programs to put MathML in a canonical form for old documents before delivering to web engines is not worse in my opinion. And there is already a lack of trust in the MathML specification because not all browser vendors have shown interest in MathML until recently, because some Math WG members and contributors seemed more interested in a theoretical standard than to consider concrete feedback from web engines developers, because the current MathML specification is too vague to implement high-quality math rendering or handle subtle rendering aspects and because the official MathML test suite is not runnable in browsers' test framework in its current form. The quick work done for the past few months on WebKit and Blink at Igalia showed that by extending / cleaning up the MathML specification and rewriting the test suite, things become much easier for web engines developers to understand, implement and test and for browser vendors to accept a proposal that integrates well in their code base. The goal of the discussion is to (re?)open a constructive collaboration with people involved in the MathML specification and with web engines developers.

To come back to mfenced, it has always been the source of bugs in Gecko and WebKit that have added maintenance cost. And it has been a burden during our refactoring in WebKit: we have spent and continue to spend *a lot of time* to avoid breaking the current support and this is as much time that could have been spent on working on more important aspects of the MathML implementation. So although there is no rush for removing that support, we believe it is important to report this issue so that it can be taken into account in the long term. As I said in the menclose thread, with the new layout rules in Blink it's very unlikely that WebKit's mfenced implementation can be accepted by Google reviewers and we do not plan to try it.
-- 
Frédéric Wang

signature.asc (836 bytes) Download Attachment