This section is non-normative.
The mstyle element duplicates the CSS inheritance mechanism in a CSS-incompatible way and has many exceptions to workaround the fact that attribute names may be used for different purposes. In practice, many of its 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. In this document, it instead suggested to keep only attributes that are compatible with CSS and five new CSS properties are introduced in section 2.3.1. These attributes actually correspond to what is used in practice.
The <mfenced> element is just a “convenient form in which to express common constructs involving fences” but is strictly equivalent to an expanded form with <mrow> and <mo> elements and has many exceptions to handle. It is thus not actually necessary and just requires more code for implementers and may lead to rendering inconsistencies with the expanded form. It requires web rendering engines to create many “anonymous” rendering frames (or similar) and keep them up-to-date which may lead to rendering, performance or security issues. Because the text of fences and separators is included in attributes and not in MathML elements then by default it may not be possible to search, select, copy it. It may also not be exposed to assitive technologies without further effort. In this document support for mfenced is not required. Authors are encouraged to use the expanded form and we recommend that the element is dropped from future version of the MathML specification.
The “radical” notation of the <menclose> element is equivalent to the <msqrt> element. Again, this adds duplicate logic for visual rendering and exposure to assistive technologies. In practice, the <msqrt> is always used for square roots. We suggest to remove the “radical” notation in future version of the MathML specification.
As explained in section 3.1.2 it is important in a HTML5 context to be able to determine the min-content width and the max-content width for linebreaking purpose. However, the mpadded element may be problematic since the pseudo-units allow horizontal metrics to depend on vertical metrics. A restriction is proposed in section 3.3.6 and should not be problematic in practice.
The TeXBook’s Appendix G as well as the OpenType MATH table rely on the “cramped” concept to adjust spacing. This is absent from the MathML specification. A simple way to determine when an element is cramped is proposed in section .