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.

[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 https://github.com/w3c/mathml/issues/216 ?

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.

[dginev]

After the MathML Core discussion today, I wanted to ask the question if we have a suggested behavior for <menclose notation="box"> - which ostensibly draws a border - and the CSS box-sizing property discussed in #257 ?

If/when that menclose variant reaches Core, it may benefit from an example comparing it to using CSS borders.

[fred-wang]

After the MathML Core discussion today, I wanted to ask the question if we have a suggested behavior for <menclose notation="box"> - which ostensibly draws a border - and the CSS box-sizing property discussed in #257 ?

If/when that menclose variant reaches Core, it may benefit from an example comparing it to using CSS borders.

CSS padding/border/margin properties are already defined in MathML Core and implemented in Chromium. They are available in development versions of Gecko and WebKit (and so probably firefox nightly and safari tech preview). So we could already re-implement box notation (left, right, top, etc) with pure CSS. That will be different from what was specified in earlier versions of MathML Core or from how menclose was implemented in Firefox/WebKit though: the bars/spacing implied by these notations are currently part of the content box while using padding/border/margin would apply to the padding/border/margin boxes (so outside the context box). AFAIK, none of these options contradict MathML 3.

[fred-wang]

Ah, and I also clarified on #257 what box-sizing is about.

[physikerwelt]

If/when that menclose variant reaches Core, it may benefit from an example comparing it to using CSS borders.

As commented in https://github.com/w3c/mathml/issues/216 (sorry if I missed the difference between both issues), I would advocate to make it not reach core for the same argument as for https://github.com/w3c/mathml/issues/61. Removing different options to get the same rendering seems a promising path to get a similar experience across different browsers.

For the table-like elements (mtable, mtr, mtd), I think it's better to use properties that also exist for (table, tr, td). The remaining elements, such as updiagonalstrike, should also be aligned with nonmath elements as much as possible.

[NSoiffer]

Is there a problem with using border for "box"? If multiple notations are given, they should all use the same inner box to size themselves. So notation="box updiagonalstrike downdiagonalstrike" should have diagonal lines that reach the corners of the box lines. Those lines should be the same size whether "box" is part of the notation list or not.

The resulting box needs to have proper padding so that an menclose around that draws around a nested menclose. I don't know if that is an issue with any of the proposed solutions, but it should be thought about to make sure that the implementation gets it right. A WPT to test for that would be good.

@tmke8: phasorangle was added at the request of (I think) some people in the EE community where is not uncommon. Here's a wikipedia article that mentions it, although they use a "primitive" version of the notation. There is a TeX package called "steinmetz" so TeX users can use that notation in their papers. I have no idea how common this package gets used. Maybe @dginev can grab some numbers from arXiv (maybe also a % of papers with the denominator restricted to the Electrical Engineering and Systems Science top level category in arXiv) ...

[dginev]

@NSoiffer the easy number I have is ~500 documents using that package in our arXiv build system. About half seem not to use any macro from it given they emit no conversion errors. Errors are expected as LaTeXML does not yet support steinmetz.sty and its \phase macro.

An example of where \phase gets used in arXiv would be ar5iv:1906.07261. A separate undefined macros report shows me an undefined \phase has been encountered in 109 documents over the entire arXiv. (the denominator is 2,332,094 documents total). Relatively rare in that collection.

[fred-wang]

For more complicated enclosing notations like phasorangle or longdiv, it may be interesting to consider recent proposals from the CSS Shape module. In particular, I imagine the border-shape property currently being discussed could be helpful:

https://github.com/w3c/csswg-drafts/issues/6997#issuecomment-2311513957

More links related to that proposal:

https://github.com/w3c/csswg-drafts/issues/10649 https://github.com/w3c/csswg-drafts/issues/10993

[NSoiffer]

@dginev: thanks for the data point. That says that it is rare in the community that uses arXiv. I wish there was some better way to know its usage in the broader world. E.g., maybe engineers use it when working out designs in their companies and it isn't something that shows up in research much. I suspect there are lots of notations like that -- all the elementary math notations are one obvious example.

[physikerwelt]

Looks like this:

For me, it does not show the strike through (in FF) https://codepen.io/physikerwelt/pen/wvVEJQK looks like abc

did I miss anything?

[dginev]

@physikerwelt I think you need a Chromium-based browser to demo CSS over MathML Core today.

[physikerwelt]

@physikerwelt I think you need a Chromium-based browser to demo CSS over MathML Core today.

I would like to use that in production. For the array grid lines, the Temml solution works very well. I can see that TEMML combines menclose and the CSS solution. In contrast, my goal is to find a solution that does not require menclose. My gut feeling is that the ability to draw a diagonal line over something is not a feature that is only useful for math notation.

If you put some content in the second mrow the diagonal line shows up in FF and no errors are shown in the FF console. Thus I'll be digging a bit further to understand the problem.