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? • July 28, 2016
- Re: Is the semantic tags example correct in https://www.w3.org/Math/whatIsMathML.html? • July 28, 2016
- Is the semantic tags example correct in https://www.w3.org/Math/whatIsMathML.html? • July 27, 2016
- [MathML4] CSS properties for MathML elements and default math font • July 27, 2016
- [MathML4] Simplification of the mstyle element • July 27, 2016
- WebKit Blog - Improvements in MathML Rendering • July 27, 2016
- Re: [MathML4] Deprecation/Removal of the mfenced element • July 27, 2016
- Re: [MathML4] Deprecation/Removal of the mfenced element • July 26, 2016
- RE: [MathML4] Deprecation/Removal of the mfenced element • July 26, 2016
- Please remove me also from this list. • July 26, 2016
- Please remove from MathML mailing list • July 26, 2016
- Re: [MathML4] Deprecation/Removal of the mfenced element • July 26, 2016
- Re: [MathML4] Deprecation/Removal of the mfenced element • July 26, 2016
- Re: [MathML4] Deprecation/Removal of the mfenced element • July 26, 2016
- Re: [MathML4] Removal of the menclose notation "radical" • July 26, 2016
- Re: [MathML4] Deprecation/Removal of the mfenced element • July 26, 2016
- Re: [MathML4] Deprecation/Removal of the mfenced element • July 26, 2016
- Re: [MathML4] Removal of the menclose notation "radical" • July 26, 2016
- Re: [MathML4] Deprecation/Removal of the mfenced element • July 26, 2016
- Re: [MathML4] Deprecation/Removal of the mfenced element • July 26, 2016
**[List of feeds]**

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! > > >> I started to read MathML intro and I bumped into this page: >> 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 in advance >> >> > 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. > > ________________________________ >

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! > > I started to read MathML intro and I bumped into this page: > 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 in advance > Thanks, fixed (added <apply><eq/>..... <cn>0</cn></apply>) 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. ________________________________

I'm a newbie in MathML, so sorry if my question seems stupid. I started to read MathML intro and I bumped into this page: 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 in advance

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 in the other thread: 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 for a later thread. 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 <math> 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 <math> tag. Per the MathML specification, authors should explicitly use the "dir" attribute on the <math> 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 <math> 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 <math> 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 <math> 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

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

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

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

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

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

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.

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

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.

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

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

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.

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

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

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

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

Planet MathML features:

- Ask.com News Search for "mathml"
- David Carlisle
- Design Science News
- FMath
- MathJax
- Murray Sargent: Math in Office
- Planetary Developer Forum: {9} Planetary News
- SF.net - ASCIIMathML
- SF.net - DocBook to LaTeX Publishing
- SF.net - MathCast Equation Editor
- SF.net - MathStudio
- SF.net - Open Math Edit
- SF.net - PyMathML
- SF.net - SVGMath
- SF.net - UniWakka
- SF.net - jsMath
- SF.net - jscl-meditor
- SF.net - pMML2SVG
- W3C Blog
- W3C Math Home
- W3C News
- Web Platform Blog
- public-digipub-ig@w3.org Mail Archives
- public-html-a11y@w3.org Mail Archives
- public-html@w3.org Mail Archives
- public-webapps@w3.org Mail Archives
- www-math@w3.org Mail Archives
- www-style@w3.org Mail Archives

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.