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.

Latest articles

[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
official WebKit twitter and blog:

https://twitter.com/webkit/status/756489720893411329

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

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

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
> <menclose notation="radical">.     
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
lead to potential inconsistencies.

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
less readable.

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
<menclose notation="radical">.

>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

[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

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 • Frédéric WANG (fred.wang@free.fr) • July 26, 2016 • Permalink

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 • Frédéric WANG (fred.wang@free.fr) • July 26, 2016 • Permalink

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
> <http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf> 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




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

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

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> 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] Deprecation/Removal of the mfenced element

Source: www-math@w3.org Mail Archives • Murray Sargent (murrays@exchange.microsoft.com) • July 25, 2016 • Permalink

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<http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf> is used to convert to <d>.



Murray




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.

(feed)This page as an Atom feed

A mechanical calculation machine (with an added W3C logo)

Bert Bos, math activity lead
Copyright © 2008–2015 W3C®

Powered by Planet