Consider adding menclose to core

[NSoiffer]

This addresses some discussion from the 24/5/24 meeting that came up in relation to what should go in in the accessibility tree.

Although menclose can be done via CSS, the CSS can be quite complicated, especially for arrowheads (see the polyfill for some css). Standardizing this via the notation attribute would simplify the MathML need. It would also enhance accessibility because strikeouts/cancellations and other modifications would be visible to AT.

Note: there is a PR about this. It references the closed issue #105.

[bkardell]

Note: It references mathml full #105, not the auto-linked 105 in this same (mathml-core) repo

[NSoiffer]

menclose seems to be a pain point wrt MathML support. On the one hand, it is in MathML 3 and supported by Webkit and Gecko. On the other hand, it can be implemented (although with sometime complicated CSS) in Chromium. In the latter case, semantics/accessibility go out the door (an important case is crossouts).

This recently came up in a discussion about MathML support in mathlive.

If you look at the differences between Core and MathML 3, the ones that aren't easy to have work in both are:

1. Linebreaking
2. Elementary math
3. menclose
4. css support

The first two are not widely implemented, so from a practical point of view, the difference is not a big deal when deciding what to generate. Getting css support into the other browsers would be great, but isn't simple. That leaves supporting menclose. That is (I think) relatively straightforward and is a potential level 2 feature because it both simplicies the use of what it does and makes the notations accessible (e.g., crossouts). Sadly, one can't use a custom element to add the support although there is a polyfill I created (example, code) that patches over some of the common differences.

Prioritizing adding menclose to MathML would go a long way to alleviating a pain point MathML developers/users currently feel.

[dginev]

Polyfills and Intent

A new consideration we will have with MathML 4 will be whether polyfills can/should use the new intent and arg attributes to also preserve sufficient information for AT.

Neil's example polyfill recovery for <menclose notation="updiagonalstrike"> could add an intent attribute on the lines of:

<mrow class="menclose" intent="enclose(up-right-diagonal-strike, $content)">
  <mrow arg="content">...</mrow>
  <mrow class="menclose-arrow" style="..."><mrow class="line"></mrow></mrow>
</mrow>

That said, if we had a new MathML 4 <menclose> with intent already deposited, we could do even better, by annotating a concept value that describes the mathematical operation. To pick an example, sometimes strikethrough is used as a notation for cancelling out, so that could become:

<menclose intent="cancel($content)" notation="updiagonalstrike">
  <mrow arg="content">...</mrow>
</menclose>

[NSoiffer]

Another accessibility example is drawing a box or circle around an mspace (other other space) to indicate a blank to be filled in. As an example

<menclose intent='blank' notation='box'>

@dginev's idea of using intent and a class would work also.

[fred-wang]

First, menclose was removed from the first release of MathML Core because it had very bad state (I mean, to present it to people as a new feature with browser's high bar requirements), even with the clarification and simplification that were in MathML Core. So it was likely to add extra effort (spec, test, implementation, 'convincing non-mathml people'). If we want to integrate it for MathML Core, I think we need to do it very carefully.

My suggestion would be:

1. Do it as a separate proposal (a PR, separate draft, or something to be merged later) with its own explainer. That will facilitate explanation when we have to do the 'convincing non-mathml people' part. We would follow browsers' usual process to develop this new feature / implementation change under a runtime flag, so we can get feedback from users before shipping.

2. Try to map to CSS as much as possible. Since MathML Core supports padding/border/margin now we could just define many notations (box, roundedbox, left, right, top, bottom and madruwb) as mapping to CSS borders which would simplify a lot of things in the four aspects I mentioned above. Maybe we could also propose CSS extensions for the other notations (that won't simplify the work though, probably add more effort and I'm not sure it will be easy for things other than the strikes).

3. Think about the use cases and consider if we can also simplify the accepted notation attribute. Are all the notations really essentials? Do we really need to support applying multiple notations to a single menclose element (or is nesting multiple menclose elements good enough)?

   Most problematic notations are actuarial (requires similar effort as <msqrt>, particularly if it is implemented as stretchy parenthesis) and phasorangle (as discussed for mfrac@bevelled stretchy slash can make the width depends on the height, breaking some CSS invariants). northeastarrow and circle have a bit of complexity too (drawing an arrow is slightly more involved, circle requires √2-spacing adjustment to avoid overlaps). Other strikes can just be done without adjusting the size. Implementation note: contrary to WebKit/Firefox, Chromium separates layout and paint classes so the ideal is if we can just determine the drawing from the content box (which is not the case for actuarial/phasorangle) so that we only need to pass around the list of notations. But even for layout only, having to deal with multiple notations and calculating extra spacing and offsets can make the code hard to write, read and maintain.

4. For the notations that don't go to CSS, define exactly the layout and painting rules (including with sizes, spacing, stroke width, color, offsets). The PR has some suggestions but this has to be reviewed after the work on 2. and 3. Also the MathML Core rule for padding/border/margin is to add everything after the math layout box, so in theory the border-based notations would be around the non-border-based notations.

5. Write WPT tests for that. I believe most existing "behave like an mrow" tests could still work since menclose is still handled as an unknown element. We need both layout tests (for children positions and sizes) and visual tests (for the notation painting). Firefox and WebKit have a few tests but they are not super accurate:

   • https://searchfox.org/mozilla-central/source/testing/web-platform/mozilla/tests/mathml/menclose
   • https://searchfox.org/wubkat/search?q=&path=LayoutTests%2Fmathml%2Fpresentation%2Fmenclose&case=false&regexp=false

   One idea for the painting is to have mismatch reftests against an mrow (to show each notation drawn at least something) and match reftest with some covering SVG drawings the notation (to show each notation does not draw outside this area). This is not super accurate, but tries to prevent flaky or platform-dependent tests. Of course, how robust our tests can be will depend on the work done in 4.

   As a comparison, for msqrt we have testharness.js tests for the layout of children as well as reftests for the visual part. Often, we use a special font that just draws the radical as a vertical bar, which makes visual reftest much more reliable.