# Planet MathML

The Planet MathML aggregates posts from various blogs that concern MathML. Although it is hosted by W3C, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of W3C.

## Re: Is the semantic tags example correct in https://www.w3.org/Math/whatIsMathML.html?

Source: www-math@w3.org Mail Archives • STF (lapsap7+mml@gmail.com) • July 28, 2016 • Permalink

On 28 July 2016 at 10:16, David Carlisle <davidc@nag.co.uk> wrote:

> On 27/07/2016 12:11, STF wrote:
>
>> I'm a newbie in MathML, so sorry if my question seems stupid.
>>
>
> Not stupid at all!
>
>
>> https://www.w3.org/Math/whatIsMathML.html
>>
>> At the end of this page, there's an example for the math expression
>> x² + 4x + 4 = 0
>>
>> But when I read the semantic tags example, I only get
>> x² + 4x + 4
>> and the "= 0" seems missing for me.
>>
>> Could someone tell me if the example is correct or not?
>>
>>
>>
> Thanks, fixed (added <apply><eq/>..... <cn>0</cn></apply>)
>
> David
>

Thank you :)

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


## Re: Is the semantic tags example correct in https://www.w3.org/Math/whatIsMathML.html?

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • July 28, 2016 • Permalink

On 27/07/2016 12:11, STF wrote:
> I'm a newbie in MathML, so sorry if my question seems stupid.

Not stupid at all!

>
> https://www.w3.org/Math/whatIsMathML.html
>
> At the end of this page, there's an example for the math expression
> x² + 4x + 4 = 0
>
> But when I read the semantic tags example, I only get
> x² + 4x + 4
> and the "= 0" seems missing for me.
>
> Could someone tell me if the example is correct or not?
>
>

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.

________________________________


## Is the semantic tags example correct in https://www.w3.org/Math/whatIsMathML.html?

Source: www-math@w3.org Mail Archives • STF (lapsap7+mml@gmail.com) • July 27, 2016 • Permalink

I'm a newbie in MathML, so sorry if my question seems stupid.

https://www.w3.org/Math/whatIsMathML.html

At the end of this page, there's an example for the math expression
x² + 4x + 4 = 0

But when I read the semantic tags example, I only get
x² + 4x + 4
and the "= 0" seems missing for me.

Could someone tell me if the example is correct or not?



## [MathML4] CSS properties for MathML elements and default math font

Source: www-math@w3.org Mail Archives • Frédéric Wang (fwang@igalia.com) • July 27, 2016 • Permalink

Hi readers of the Math WG mailing list,

In a previous message, Murray Sargent indicated that his two main
complaints about Presentation MathML were "1) lack of an explicit n-ary
element (for integrals, summations, products, etc.) and 2) lack of
document level math properties, like default math font". However, MathML
already has a mechanism to describe such n-ary constructions based on
the mo/munderover/msubsup elements and the largeop property ; Gecko &
WebKit rely on them to use the appropriate layout constants. The second
point is more interesting (especially fonts) so let's open a discussion
here.

As you know, stylistic properties in web engines are described using
CSS. All Web authors are familiar with this mechanism and it is a very
important feature for them. Users of web browsers can also use custom
user stylesheets to specify their preferred default style, possibly
overriding the one of page authors. However, the MathML specification
does not say much about CSS and so web engines developers have to do
their own interpretation, leading to incompatibilities between
implementations. Some parts of the discussion below may be out of the
scope of the Math WG but I think some hints should be provided in the
MathML specification anyway.

First, CSS is much more powerful than the <mstyle> inheritance
mechanism. That latter element should probably be made compatible with
CSS or at least should reuse it as much as possible. This is discussed
https://lists.w3.org/Archives/Public/www-math/2016Jul/0024.html

The specification should probably also explain how many CSS properties
(e.g. margin, padding, border etc) should be handled for MathML. At the
moment, Gecko and WebKit essentially ignore these properties in most
cases. Anyway, the MathML specification is too vague about the exact
rendering of math elements to open this discussion so I'll postpone it

The default visibility for the mphantom element should be "hidden".
Although it can be hidden by other mechanisms, using CSS is the most
natural way to do it and this also has implications in other parts
outside the rendering module (e.g. the a11y module).
Many properties should be reset on the [itex] element to avoid
unexpected things. Here is a non-exhaustive list extracted from bug reports:

* Inheriting the following properties can cause excessive spacing of
mathematical formulas: text-indent, line-height, word-spacing,
letter-spacing.

* In some countries and languages, text is written from right-to-left
while mathematical formulas are written from left-to-write. Hence it is
wrong to inherit the direction and we reset that property to
left-to-write on the [itex] tag. Per the MathML specification, authors
should explicitly use the "dir" attribute on the [itex] element if they
want to force the overall direction of the mathematical formulas.
Similarly, the writing-mode should probably be set to "horizontal-tb" by
default.

* Some properties give poor rendering in math formulas or are confusing
with the mathvariant style. They should be reset too. This includes at
least font-style or font-weight.

Finally, one of the most important issue is the choice of the math font.
Note that most stylistic math properties are actually included in the
font itself so it's great that authors can just use the CSS font-family
to select their preferred fonts (possibly provided as Web fonts), and
make it consistent with the rest of the page. However, to determine the
default math fonts, some mechanisms should probably be formalized and
implemented in web engines:

1) Text fonts are not appropriate for math layout. Hence making the
[itex] element inherit the text font is a very bad idea. Ideally, web
engines should have a mechanism to try and find math fonts in the
specified CSS font-family lists and to fallback to known math fonts on
the system.

2) One consequence is that we are likely to get different text and math
fonts and so inconsistent font-size. Instead of making the [itex]
element inherit the font-size, Web engines should probably have a
mechanism to automatically adjust the font-size.

3) Even with this adjustment, the style of the font faces of the text
and math fonts may be inconsistent. Many text fonts have a math
companion e.g. STIX / STIX Math, Latin Modern Roman / Latin Modern Math,
DejaVu Serif / DejaVu Math TeX Gyre etc It would be good to have a
mechanism to map a font to its math companion (probably this should be
discussed on the Open Font Format mailing list). Then the font-family
can be determined using this mapping and this solves all the issues of
inconsistent style and font-size.

So to summarize, the idea to determine the default font-family /
font-size on the [itex] element would be: a) find a math font that fits
best (font-size and fontface style) with the inherited font-family and
b) adjust the font-size if necessary to match the parent font-size.

Finally, for the record the user agent stylesheets of WebKit and Gecko
are available here:
https://trac.webkit.org/browser/trunk/Source/WebCore/css/mathml.css
https://dxr.mozilla.org/mozilla-central/source/layout/mathml/mathml.css

Frédéric


## [MathML4] Simplification of the mstyle element

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • July 27, 2016 • Permalink

Hi,

Continuing with suggestions for future Math WG work, let's come back
again to the idea of simplifying the mstyle element. It duplicates the
CSS inheritance mechanism in a CSS-incompatible way and has many
exceptions that make it hard to understand: there are three different
types of inheritance described in the specification, mathbackground
applies more naturally to the element that bears the attribute than to
each token descendants, mpadded/mspace share attributes names that have
different syntax etc For example, in previous discussions the case of
displaystyle seemed really clear in the mind of spec authors but less in
the one of the various implementers.

In practice, many of the mstyle attributes are not useful and never
used. It is a burden for implementers since they essentially have to
reimplement a specific "attribute" inheritance mechanism to support the
general case even if the most prominent attributes have obvious mapping
to CSS. It is also a performance issue to perform the rendering and keep
it up-to-date since the rendering on any node may depend on its mstyle
ancestors.

Support for mstyle has been simplified in Gecko several years ago. When
this was reported to this mailing list, there have not been strong
complaints against the idea (only a few extra attributes were reported
to be used in the MathML3 test suite). There has not been any bug
reports regarding removal of attributes, confirming they were not used
(this contrasts with the case of displaystyle for which aligning on the
specification caused some trouble). Support for some important mstyle
attributes have been implemented in WebKit but there are no plans to
handle the general cases.

Given this, the proposal is as follows: restrict mstyle to attributes
used in practice listed below. Also the inheritance can in most cases be
more easily described with CSS rules or attribute mapping.

1) dir: mapped to the CSS direction property.

2) mathsize: mapped to font-size. Note that MathML has the keywords
"small", "normal", "big" that adds some parsing code before the mapping.
It's not clear whether these keywords are very important (small is 100%,
small/big are unspecified...) so they could be deprecated too to
simplify the mapping code.

3) mathbackground: mapped to CSS background property.

4) color: mapped to CSS color property.

5) displaystyle: this one will be preserved but inheritance can be more
clearly described to people familiar with CSS as equivalent to having a
CSS property with values false/true, which is inherited, has computed
value "as specified" and with the following rules in the user agent
stylesheet.

math {
displaystyle: false;
}
math[display="block"] {
displaystyle: true;
}
math[display="false"] {
displaystyle: false;
}
math[displaystyle="false"] {
displaystyle: false;
}
math[displaystyle="true"] {
displaystyle: true;
}
mtable {
displaystyle: false;
}
mtable[displaystyle="true"] {
displaystyle: true;
}
mstyle[displaystyle="false"] {
displaystyle: false;
}
mstyle[displaystyle="true"] {
displaystyle: true;
}
mfrac > * {
displaystyle: false;
}
mroot > :not(:first-child) {
displaystyle: false;
}
msub > :not(:first-child),
msup > :not(:first-child),
msubsup > :not(:first-child),
mmultiscripts > :not(:first-child) {
displaystyle: false;
}
munder > :not(:first-child),
mover > :not(:first-child),
munderover > :not(:first-child) {
displaystyle: false;
}

6) mathvariant: this one will be preserved but inheritance can be more
clearly described to people familiar with CSS as mapped to a CSS
property with all the mathvariant values + an "auto" value (to handle
automatic italic), initial value "auto", which is inherited and has
computed value "as specified".

7) scriptsizemultiplier: can be described as a CSS property with
<number> values, initial value 0.71, computed value "as specified" and
which is inherited. It's not clear whether the attribute is really
useful as in practice it is left to its default value. Also this is in
conflicts with ScriptPercentScaleDown and ScriptScriptPercentScaleDown
properties of the MATH table.

8) scriptminsize: can be described as a CSS property with <length>
values, initial value 8pt, computed value "as specified" and which is
inherited. Again, it's not really clear whether the attribute is useful
as in practice it is left to its default value.

9) scriptlevel: This one must be preserved but it is not clear whether
it can be described as a pure CSS property without adding too much
complexities. There is a proposal on
http://www.mathml-association.org/MathMLinHTML5/S2.html#SS3 but the
increment in munderover/munder/mover should really depend on the
accent/accentunder property which itself depends on specified attributes
or implicit/explicit operator properties in the overscript/underscript
subtrees.

A rule to determine the computed value for font-size must also be
provided, for example:

FontSize_Child =
max of ScriptMinSize_Parent and
[FontSize_Parent times
ScriptSizeMultiplier_Parent^(FontSize_Child - FontSize_Parent)]

with possible additional edge cases to handle.

Unless something has been forgotten above, all the other mstyle
attributes could be safely deprecated and removed.

--
Frédéric Wang



## WebKit Blog - Improvements in MathML Rendering

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • July 27, 2016 • Permalink

FYI, the announcement of MathML improvements has also be made on the

https://webkit.org/blog/6803/improvements-in-mathml-rendering/

In my previous announcement on this mailing list, I mentioned that the
changes will be in Safari Technology Preview on OS X. Paul Libbrecht
wrote to me to indicate that the changes are probably likely to be in
the next version of the system renamed "macOS" and of the next version
iOS, and maybe some other developer preview. As usual, this is not sure
(see https://trac.webkit.org/wiki/FAQ#Releases) so I preferred not to
comment on that and let people check by themselves when these releases
happen...

--
Frédéric Wang



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

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • July 27, 2016 • Permalink

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



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

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • July 26, 2016 • Permalink

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.

________________________________


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

Source: www-math@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • July 26, 2016 • Permalink

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:whammond@albany.edu] On Behalf Of William
F Hammond
Sent: martes, 26 de julio de 2016 20:09
To: www-math@w3.org
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
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>,

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


## Please remove me also from this list.

Source: www-math@w3.org Mail Archives • SFU Account (jlester@sfu.ca) • July 26, 2016 • Permalink




## Please remove from MathML mailing list

Source: www-math@w3.org Mail Archives • Andy Keyworth (akeyworth@tbase.com) • July 26, 2016 • Permalink

Hi,

Would you kindly remove my email address from the mailing list?

Thank you,

Andy Keyworth
Online Accessibility and Product Development Specialist
T-Base Communications
Phone: 613-236-0866 | Toll free: 1-800-563-0668 x1256
www.tbase.com<http://www.tbase.com/> | Ogdensburg, NY | Ottawa, ON
For accessibility stories to inform & inspire, follow #tbasestories<http://tbase.com/blog-tags/t-base-stories>!
SIMPLIFYING ACCESSIBLE COMMUNICATIONS.TM

This email may contain information that is privileged and confidential. If you have received this communication in error, please delete this email message immediately.


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

Source: www-math@w3.org Mail Archives • William F Hammond (hammond@csc.albany.edu) • July 26, 2016 • Permalink


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

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


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

Source: www-math@w3.org Mail Archives • Miller, Bruce R (Fed) (bruce.miller@nist.gov) • July 26, 2016 • Permalink

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 <smwatt@gmail.com>
Sent: Tuesday, July 26, 2016 8:49:04 AM
To: Frédéric WANG
Cc: www-math@w3.org
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 <fred.wang@free.fr<mailto:fred.wang@free.fr>> 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.


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

Source: www-math@w3.org Mail Archives • Jason Harris (jasonh@wolfram.com) • July 26, 2016 • Permalink

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


## Re: [MathML4] Removal of the menclose notation "radical"

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • July 26, 2016 • Permalink

Le 26/07/2016 à 14:06, Stephen Watt a écrit :
> I don't see why there would be inconsistencies in implementation.   A
> reasonable developer would just have <msqrt> call the same code as
It depends what you mean by "call the same code". Also note that mroot
has similar layout but some differences (more parameters for the index,
only two children and no inferred mrow).

In WebKit, msqrt & mroot share the same C++ class. In the past, the code
of msqrt was reused for menclose by creating anonymous nodes which
caused complaints from Google at the time they review it and will make
things even worse now that they are moving to stricter rules for their
layout classes. Fortunately menclose@notation was removed so it's no
longer an issue.

In Gecko, msqrt & menclose share the same C++ class. At the moment it
does not share code with mroot so there are duplicate logic which may

Personally, I would say it's best to share msqrt / mroot implementations
as they have clear and simple rules to perform the layout. menclose has
many notations, must handle multiple notations at the same time and is
more complex, so merging it into msqrt (as done is Gecko) makes the code

Frédéric

PS: Some developers will be happy to know that they are "unreasonable":
https://github.com/mathjax/MathJax/issues/101



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

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • July 26, 2016 • Permalink

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.



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

Source: www-math@w3.org Mail Archives • Stephen Watt (smwatt@gmail.com) • July 26, 2016 • Permalink

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 <fred.wang@free.fr> 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.
>
>
>


## Re: [MathML4] Removal of the menclose notation "radical"

Source: www-math@w3.org Mail Archives • Stephen Watt (smwatt@gmail.com) • July 26, 2016 • Permalink

Hi Frederic,

I don't see why there would be inconsistencies in implementation.   A
reasonable developer would just have <msqrt> call the same code as

>From a software engineering point of view, I would think it would make more
sense to remove <msqrt>.   But from a "give the people what they think they
want" point of view, I would think we need to keep it.

Stephen

On Tue, Jul 26, 2016 at 3:29 AM, Frédéric WANG <fred.wang@free.fr> wrote:

> Hi everybody,
>
> Continuing on proposal for MathML4, there are two equivalent notations
> for square roots:
>
> * <msqrt> child1 child2 ... child3 </msqrt>
> * <menclose notation="radical"> child1 child2 ... child3 </menclose>
>
> The latter does not bring anything new but duplicate code or
> inconsistencies in implementation. In WebKit, the msqrt and mroot
> elements share implementation and menclose@radical was implemented by
> creating anonymous nodes. In the past, this kind of implementation has
> led to rendering, performance and design/security issues. During phase 1
> of our refactoring [1], we thus removed support for menclose@radical. In
> Gecko, the msqrt and menclose elements share implementation but then
> mroot has duplicate logic, which is bad and Gecko should probably be
> aligned on WebKit here.
>
> So we would like menclose@radical to be removed in future versions of
> MathML (it is optional in MathML3 anyway). We expect this removal to be
> safe for the users given that (except in examples and tests) msqrt is
> always preferred over menclose@radical in math documents. The only
> rationale for menclose@radical would be to write overlapping notations
> (e.g. <menclose notation="radical circle horizontalstrike">) but again
> we are not aware of any concrete use cases for that and it's always
> possible to nest <msqrt> and <menclose> to get similar rendering without
> overlapping notations.
>
> Frédéric, for the Igalia Web Platform team
>
> [1] https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring
>
>
>
>


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

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • July 26, 2016 • Permalink

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.

________________________________


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

Source: www-math@w3.org Mail Archives • Miller, Bruce R (Fed) (bruce.miller@nist.gov) • July 26, 2016 • Permalink

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 <smwatt@gmail.com>
Sent: Monday, July 25, 2016 6:00:04 PM
To: Frédéric WANG
Cc: www-math@w3.org
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 <fred.wang@free.fr<mailto: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


## Feeds

Planet MathML features:

If you own a blog with a focus on MathML, and want to be added or removed from this aggregator, please get in touch with Bert Bos at bert@w3.org.