Include mo@accent attribute into MathML Core?

[fred-wang]

This is a follow-up of w3c/mathml#151 and w3c/mathml#76 and w3c/mathml#164

mo@accent duplicates what is provided by munderover's accent attribute and violates the CSS logic of having properties depending on parents not on arbitrary descendants. As I said elsewhere I think it should just be removed and not implemented in Chromium.

I'm just opening this to put the ISSUE label on the spec.

[NSoiffer]

Adding it to the record:

This was discussed in w3c/mathml#151 comment and in a 30 March meeting leading to two comments in w3c/mathml#164 about this (comment1, comment2 , the later I mistakenly referred to cramped style when I meant the close in spacing of accents)

The main points are:

• Almost all WYSIWYG editors and TeX converters today don't use the accent property on mover, etc. So virtually all use of accents would break.
• The proposed change to the spec is minimal -- remove "embellished" from the phrase "embellished operator" in a few places in the spec.
• It a minimal change to the code
• It solves the CSSish problem of having to search into the children.

As for whether this affects usages of accents, even Patrick Ion, who seemingly has seen every weird math notation someone has used in an esoteric field of math couldn't recall an accent being embellished, so this restriction would not affect real math. The case of having (say) a double hat would be done by nesting the mover, not nesting the mo as in

<mover> 
  <mover>
    <mi>x</mi>
    <mo>^</mo>
  </mover>
  <mo>^</mo>
</mover> 

[fred-wang]

I removed mo@accent from the current text.

In general MathML3 has a lot of issues with accents (not only font-size, but also combining VS non-combining, TopAccentAttachment, spacing parameters etc), we really need to rely more on CSS and OpenType to improve it this is definitely not something for a first version / implementation, if we want to keep the spec clean.

If we redefine mo@accent in a future version we should ensure that it is compatible with web platform design and so can get browser implementers' interest. In the meantime, it should be easy for users to use CSS to tweak the rendering. Some of the issues we discussed:

• Default value depends on the text content of the mo (We decided to change it to "true" but it's not fixed in the full spec yet)
• Violate minimality principle since it duplicates accent/accentunder attributes (if we put it back, we'll need to define order of priorities)
• Violate CSS design since it requires to check children arbitrary deep in the tree (should probably become an mo attribute only, not an embellished operator property)
• No CSS selector for things like "the first child of an munderover whose third child is an mo with an accent='true' attribute" to implement cramped (Brian mentioned there is a CSS selector that has been discussing since forever to allow that but never got traction from implementer).

I guess a first step would be to work on addressing these issues in MathML Full and to work on polyfills to demonstrate the desired behavior, and convince potential implementers.

[NSoiffer]

I've written a polyfill for this: https://github.com/mathml-refresh/mathml-polyfills/tree/master/accent

[NSoiffer]

At the MathML Core meeting today, I was tasked with showing examples of accents and how various renderers are handling them. I created a codepen with some examples and the renderings of this are shown below (minus the JS for Firefox & Safari):

MathJax

Firefox

Safari

Notes on accents and limits

• In MathML 3 (which is what the renderers should follow), the operator dictionary determines whether an mo should be treated as an operator. In the examples, the "^" and the "→" have the accent property, the "=" does not. The mrow with "x→y" should not be treated as an accent by default.
• The difference between an accent and a limit is that the limit is shrunk in size and is drawn further away from the base; accents should use the same font size as the base.
• If accent is set on mover, then it overrides the operator dictionary.
• 'stretchiness' should not be affected by the accent property. It is a function of the font and the renderer's capabilities.

Notes on the renderings

• Each rendering used different fonts, so they aren't exactly comparable
• All are rendered at 18 point (with MathJax, I used the context menu "math settings/scale all math.../150%"
• Firefox appears to render the cases correctly, but has a very small difference in the spacing used between accents and limits (probably too small, but MathML 3 doesn't specify the amount).
• Safari appears to handle spacing correctly, but shrinks the size of accents in all cases

I will file a bug with MathJax about its messed up stretchy arrow. It only happens when I scale the font.

Conclusion

All the renders implement the accent property on mo and mover as per the MathML 3 spec, although Safari doesn't render accents as per the spec because it always shrinks the font.

[NSoiffer]

Here's a rendering from Igalia's chrome branch (thanks to @bkardell) :

This shows that it also implements the accent property on mo and mover as per the MathML 3 spec.

[bkardell]

Just for clarity, the screenshot is from our downstream fork from last year with our initial take. Upstreaming requires a lot of additional scrutiny and changes*

[fred-wang]

There is no plan to implement mo@accent in Chromium's initial implementation. Instead, we implemented the accent/accentunder attributes on underover scripts described in the spec. I think discussion should be postpone for level 2.

[NSoiffer]

Here's Chrome Canary's rendering (19/2/22; V 99.9.4840.0) of the above (same codepen as above but with the scripting for MathJax removed):

Clearly the Chrome implementation doesn't (yet) implement the accent property's positioning regardless of where it is set or inherits from. Also missing from the implementation is horizontal stretching, but that's a separate feature.

As already discussed, removing this feature from Core is a breaking change to common/everyday MathML. As such, it violates one the charter's tenets.

[dginev]

Almost all WYSIWYG editors and TeX converters today don't use the accent property on mover, etc. So virtually all use of accents would break.

For \hat{a}, one gets:

1. <mover accent="true"> with no accent attribute on the <mo> in:

   • latexml, katex, tralics,

2. mover and mo with no accent attribute anywhere:

   • mathjax,

3. pure unicode â, no MathML:

   • pandoc, tex4ht

4. <mover> with an <mo accent="true">

   • pandoc, tex4ht - for larger bases (e.g. a+b) and explicitly requested mathml output

Some of the modern converters just delegate to the polyfills (asciimath, lwarp), and some of the old ones still generate images (latex2html). I have no idea about the Windows-only toolchains.

Just dropping a comment, since I found the claim that "almost all TeX converters today don't use the accent property on mover" a bit odd, when three of them do. Clearly this is a decision with some complex trade-offs. I wonder if it's worth reaching out to the pandoc and tex4ht teams and asking them if they can transition smoothly?

[bkardell]

Discussed on the call today, resolved to contact the MathJax team and see if they are able to generate accent=true on mover for some day in the future when there is a MathML-Core output support. (Neil will take the action). If they are willing to do that (as they are ~95% of the output), then we will remove accent on the mo in the spec as suggested in the issue. A secondary issue can be opened in full.

[NSoiffer]

FYI: I checked MathType and it uses accent on mover. Murray did the same for Word's editor and found the same. However, the WIRIS editor does not use accent on mover.

[NSoiffer]

I heard from David Cervone (MathJax) that they are able to generate accent=true on mover for some day in the future.

Closing because this was the condition that was the remaining issue to accepting it.