Accent commands serialize as `<mover>` without `accent="true"`, losing the accent/limit distinction for non-browser MathML consumers

[shbernal]

Accent commands serialize as <mover> without accent="true", losing the accent/limit distinction for non-browser MathML consumers

Summary

Temml renders accent commands (\hat, \bar, \vec, …) as an <mover> element
without the accent="true" attribute. In a browser this renders correctly, because
MathML Core derives the accent behavior from the operator dictionary and Temml adds CSS
nudge classes on top. But the serialized MathML no longer carries the accent semantics
explicitly, so downstream consumers that don't implement the operator dictionary
(MathML→OMML converters, some assistive tech) cannot distinguish an accent from an
over-limit.

I can see this is deliberate — src/functions/accent.js has:

if (group.label !== "\\vec") {
  accentNode.style.mathDepth = "0" // not scriptstyle
  // Don't use attribute accent="true" because MathML Core eliminates a needed space.
}

So this isn't a report that the attribute was forgotten; it's a request to find a way to
preserve the accent/limit distinction in the serialized output without regressing the
MathML Core spacing you're protecting with that comment. I don't have a
regression-free patch to offer yet, which is why I'm opening this as a discussion rather
than a PR.

Reproduction

import temml from 'temml'
console.log(temml.renderToString('\\hat{a}', { displayMode: true }))

Emitted MathML (inner content):

<mover><mi>a</mi><mo stretchy="false" class="wbk-acc" style="math-depth:0;">^</mo></mover>

The <mover> has no accent="true" attribute. (Confirmed on 0.13.3.)

Why it matters (concrete downstream example)

Converting Temml's output to OMML with
mathml2omml — to author native PowerPoint
equations — keys off the accent attribute:

• <mover accent="true"><mi>a</mi><mo>^</mo></mover> → <m:acc> (accent — script hugs the base)
• <mover><mi>a</mi><mo>^</mo></mover> → <m:limUpp> (over-limit — wrong spacing/semantics)

Because the attribute is absent, \hat{a} becomes a limit-over construct in the resulting
.pptx rather than an accent. Such consumers don't implement the MathML Core operator
dictionary, so they have no other signal to recover the accent from.

Affected commands

All overscript accents route through the same mathmlBuilder in
src/functions/accent.js and are affected: \hat, \bar, \vec, \dot, \tilde
(and siblings \ddot, \acute, \grave, \check, \breve, \widehat, \overline, …).
The under-accent path (\c → <munder>) would analogously want accentunder="true".

Possible directions (for discussion)

I don't want to reintroduce the spacing regression your comment guards against, so I'm not
proposing to unconditionally set the attribute. Some options that might thread the needle —
open to your judgment on which, if any, is acceptable:

1. Opt-in flag — a Settings option (e.g. accentAttr: true, default false) that
   emits accent="true" / accentunder="true" for consumers that want spec-explicit
   accent semantics and aren't relying on MathML Core layout.
2. Emit the attribute and compensate for the lost space in CSS — if the "needed space"
   the comment refers to can be restored via the existing per-character nudge classes
   (chr-* / wbk-*), the attribute could be set unconditionally with no visible change.
   I'd need a browser-side check to confirm this is genuinely rendering-neutral before it
   would be worth a PR.
3. Document the limitation — note in the docs that serialized Temml MathML relies on
   the operator dictionary for accent semantics, so downstream converters should treat the
   accent operators (or Temml's accent classes) accordingly.

Happy to prototype whichever direction you prefer, or to leave it as a documentation note
if you'd rather not carry the option.

Environment

• temml 0.13.3 (Node, renderToString(..., { displayMode: true }))

[ronkok]

You are correct when you say that Temml deliberately omits accent="true" from any <mover> element. There is a rendering issue in the Chromium and WebKit browsers. They render an accent too close to the base element when accent="true". This appears to be not only a browser issue, but also an issue in the MathML-Core specification. The specification's own documentation displays an example of the problem.

It's possible that this issue arises because math fonts report the wrong base height in their OpenType MATH table. I have not done a thorough investigation. But one way or another, those two browser engines render accents badly if accent="true".

Temml therefore omits the accent="true" attribute and instead it sets a custom value for style="math-depth" to get a correctly sized accent.

While writing Temml, I have concentrated on getting MathML output that renders well in browsers. Temml contains several workarounds that correct bad browser behavior and may render poorly in other user agents. If I add a rendering option, I'd like to do it just once for all the browser workarounds, not just this one.

Temml's workarounds are mostly done via a CSS class. So other user agents can just omit the CSS rule and get good rendering. But some workarounds, such as <menclose> workarounds, involve more extensive changes. If I start down this path of supporting other user agents, there is potentially a lot of work ahead.

I'll think about it and address this in a day or two. I'm booked up for the next couple of days.