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 w3c/mathml#105.

[bkardell]

Note: It references mathml full w3c/mathml#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.

[physikerwelt]

This seems to be a very complex topic. To get an overview, I would like to understand

1 How does this issue differentiate from #274 ?

2 Is there a MathML core alternative to represent \cancel https://en.wikipedia.org/wiki/Cancelling_out, which is frequently used?

[NSoiffer]

I believe that this can be accomplished with CSS via a transform that involves rotate and translate. I also see my menclose polyfill also sets left. See ARROW_INFO and lines 457-475. It is kind of messy and requires measuring the box of the contents, so I'm not sure this can be done in pure CSS. But maybe there are some clever hacks that allow you measure something and use that as a CSS length.

However, and this is the problem with using CSS for things that are more than stylistic such as cross-outs, this is invisible to AT. Potentially, intent can be used to make this accessible.

[physikerwelt]

However, and this is the problem with using CSS for things that are more than stylistic such as cross-outs, this is invisible to AT. Potentially, intent can be used to make this accessible.

For Wikipedia, we have implemented basic infrastructure for intent. Thus, I think this could be an option.

On the other hand, displaying the cancel symbol is the main concern and the top 1 pressing issue for Wikipedia. The chances are not very high that we could use the JS polyfill, as people might have disabled JS. I was trying to understand how, for example, MathJax, when using CHTML, generates the HTML. In my browser, I see the following output for $\cancel{x}$. However, this is neither HTML nor MathML core.

It would be interesting if there is more information on how one can use only MathML core and CSS to get the desired rendering.

1. What is the element that is rotated and translated?
2. Does the element that needs be crossed out be modified in any way?

[tmke8]

how one can use only MathML core and CSS to get the desired rendering.

Temml does it like this:

<!doctype html>
<title>cancel with CSS</title>
<style>
  mrow.menclose {
    position: relative;
    padding: 0.5ex 0ex;
  }

  .upstrike {
    display: inline-block;
    position: absolute;
    left: 0.5px;
    bottom: 0;
    width: 100%;
    height: 100%;
    background-color: currentColor;
    clip-path: polygon(0.05em 100%, 0em calc(100% - 0.05em), calc(100% - 0.05em) 0em, 100% 0.05em);
  }
</style>

<body>
  <math>
  <mrow class="menclose">
    <mrow>
      <mi>a</mi>
      <mi>b</mi>
      <mi>c</mi>
    </mrow>
    <mrow class="upstrike"></mrow>
  </mrow>
  </math>

Looks like this:

EDIT: fixed wrong end tag

[tmke8]

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)?

Looking at the defined notation values in MathML 3,

"longdiv" | "actuarial" | "phasorangle" | "radical" | "box" | "roundedbox" | "circle" |
"left" | "right" | "top" | "bottom" | "updiagonalstrike" | "downdiagonalstrike" |
"verticalstrike" | "horizontalstrike" | "northeastarrow" | "madruwb"

I'd say only updiagonalstrike, downdiagonalstrike, verticalstrike, and horizontalstrike are really essential. The others are either relatively obscure (like phasorangle) or very easy to do with CSS (like box).

[physikerwelt]

For Wikipedia, the grammar is fixed. There is only cancel, cancelto and matrix, which generate menclosed.

In this context, the following constants are being used in the code

"left" | "right" | "top" | "bottom" | "updiagonalstrike" | "downdiagonalstrike" | "northeastarrow" | "updiagonalarrow"

updiagonalarrow was missing from the list above. And I hope there are better alternatives for matrix, so that we can get rid of lrtb.

[physikerwelt]

For the table (lrtb) TEMML does it with style attributes on the mtd elements as well. We use the rowlines attribute.