Operator spacing adjacent to <mtext>

[ronkok]

This issue concerns operator spacing. Currently, MathML Core section 3.2.5.1 notes that operator spacing is affected by whether adjacent elements are space-like, which is good. It also declares that the <mtext> element is space-like, which is contrary to established practice.

Consider the LaTeX expression (1) \( \text{abc} = \text{def} \). For purposes of operator spacing, TeX treats those \text{…} expressions the same as an ord atom. The = operator gets a medium space on both sides. MathML Core should do likewise and treat <mtext> as being non-space-like. Currently, the MathML expression <mtext>abc</mtext><mo>=</mo><mtext>def</mtext> does not give operator spacing to the operator.

I have a hypothesis about how the misunderstanding may have occurred. Consider the LaTeX expression (2) abc\( = \)def. TeX does not give extra spacing to the operator in that expression.

I contend that the proper treatment in MathML Core should be as in expression (1) above, not expression (2). The \(…\) delimiters in the expression are the analogue of the <math>…</math> element. \text{…} is the analogue of <mtext>.

Here is a visual confirmation of these LaTeX expressions.

For a slightly off-topic note, I cannot find anywhere in the spec that actually sets out the operator spacing rules for <mo>, given various adjacent elements. It seems to me that something like the table in the TeXbook, page 170 would be useful. This historical note contains some relevant information.

[dginev]

@ronkok Consider also that the example used in the spec recognizes another established practice, which is to include leading/trailing whitespace in the \text argument:

 <mtext>&nbsp;if&nbsp;</mtext>

And this is yet further complicated with <mtext> being the main available carrier element for embedding HTML content.

Making either strict choice for spacing vs non-spacing would be comparably wrong, as it is the contents of the <mtext> which are or aren't space-like.

[ronkok]

@dginev When I include whitespace inside a \text argument, it is typically to get some spacing when adjacent to a ord atom, not a rel atom. Treating <mtext> as non-space does not change that use case. Although it may point out the need for a more detailed specification of spacing between the various types of adjacent elements.

The committee may throw up its hands, declare that no spec can correctly handle all contingencies, and decide to keep section 3.2.5.1 as is. If so, I would like to see that so declared. Then MathML authors can at least write spacing workarounds with the confidence that future specs will not break their documents.

[dginev]

Then MathML authors can at least write spacing workarounds with the confidence that future specs will not break their documents.

The hope that no future version of MathML will reverse a decision taken today (especially when it comes to operator spacing) is quite optimistic.

If you want to be 100% certain in the spacing of your operators, I suspect using lspace and rspace attributes is a better long-term strategy.

[davidcarlisle]

Admitedly the definition is slightly arbitrary, but this is not new, it's been the same in all previous versions, for example

MathML3 https://www.w3.org/TR/MathML3/chapter3.html#id.3.2.7.4

and back in 1999 with MathML1.1 https://www.w3.org/1999/07/REC-MathML-19990707/chap3_2.html#sec3.2.6

As such I don't think it would be easy to change for MathML core.

[ronkok]

I don't think it would be easy to change for MathML core.

I suspect using lspace and rspace attributes is a better long-term strategy.

Point taken. I'll start a revision for Temml.

Moderator: Feel free to close this issue with a won't fix. There's no need to wait for a committee meeting. I think I see how this issue will play out.

[ronkok]

It turns out that a lspace and rspace approach will not work. When a <mo> element is located between two <mtext> elements, Chromium ignores lspace and rspace attributes on the <mo> element. I also tried wrapping the <mo> with an <mpadded>. In that case, Chromium recognized the lspace, but the rspace was broken.

I am currently placing <mspace> elements on both sides of the <mo> element. Unlike the lspace|rspace approach, the new <mspace> approach will render improperly if the MathML Core spec ever changes section 3.2.5.1. So I renew my request that the committee consider this issue. I expect the decision will be to leave things as is, but that should be on the record in case some future committee examines the same issue.

[dginev]

When a element is located between two elements, Chromium ignores lspace and rspace attributes on the element.

This sounds like a browser bug I think. We should probably add a test to wpt as well.

[tmke8]

Regarding the original question: even though there is this sentence in the spec:

This is because operator spacing is affected by whether adjacent elements are space-like.

It's hard for me to identify any situations where being space-like actually matters in current browser implementations. For example, consider:

<math display="block">
    <mrow>
        <mspace width="0"/>
        <mo>+</mo>
        <mi>a</mi>
    </mrow>
</math>

The spec seems clear that + should be considered in prefix form, because

If the embellished operator is the first in-flow child of a grouping element, mpadded or msqrt with more than one in-flow child (ignoring all space-like children) then it has form prefix.

But the latest Firefox and Chrome display it as if it was infix.

Here they display it correctly as prefix:

<math display="block">
    <mrow>
        <mo>+</mo>
        <mi>a</mi>
    </mrow>
</math>

[NSoiffer]

There was a discussion about this at the meeting. We did not come to a conclusion, but there did seem to be movement towards removing mtext from the list of space-like elements because it can contain non-space content that is mathematically meaningful ("not", "iff", ...) and also because one can put arbitrary HTML inside of it.

[NSoiffer]

This was discussed at the MathML Full meeting on 30 Oct and the feeling was that both core and full should change and make mtext space-like only if it contains only Unicode spacing characters (but not the space, cr, or nl chars).