Add menclose to MathML core

[fred-wang]

Opening a new issue to track needed work for menclose ( PR of the original text: #24 ).

Known issues:

• Simplify: Simplification of the menclose element mathml#105

• menclose does not specify in which order the notations are painted ( menclose does not specify in which order the notations are painted mathml#113 )

• need OpenType MATH values if a dedicated algorithm is provided ( OpenType MATH values for menclose notations  mathml#97 )

Instead of a dedicated algo, it would be better if menclose would just use the current mrow algo and rely on pure CSS for styling notations.

[NSoiffer]

I don't think order matters for the current set of values. However if it does need to be specified because of some CSS properties, the order in which they are listed seems reasonable to me.

[NSoiffer]

This was discussed at the CG meeting today. From the notes:

• FF/Webkit support menclose and almost all of the attrs
• @bkardell suggested that maybe a UA stylesheet would be a trivial way to implement some of them for level 1, but eventually withdrew his suggestion

The CG felt menclose was important and since the other browsers implement it but Igalia currently doesn't plan to do it, this should move to level 2. There should be a polyfill to handle this.

[NSoiffer]

Filling in some details on the earlier comment...

I created a codepen sweep test of the attributes.
Results:

• Firefox: does all the ones listed in MathML 3 except northeastarrow (and other arrows which are listed as maybes)
• Safari: all except radical, pahasorangle, and northeastarrow
• MathJax: supports everything including all arrows lists as maybes

[physikerwelt]

We discussed that in the last meeting, and it seems that it is very unlikely to make progress here soon. Following the discussion on #245 it seems that there are good alternatives to menclose using CSS.

From the issue description

Instead of a dedicated algo, it would be better if menclose would just use the current mrow algo and rely on pure CSS for styling notations.

One can ask onself the question, why do we menclose at all. Woudn't it be better to convert the current usages of menclose as a one off and document how the conversion can be done? If we, for example, had an XSLT that transforms from menclose to the mrow that would be (after having thought about it for a while) better. Otherwise, handling interference with existing CSS attributes might add an extra level of complexity.

Thus instead of leaving this open for an extended period of time my suggestion is to close this issue and document that menclose won't be supported.

Reactions using thumps up / thumps down are most welcome.

[dginev]

Woudn't it be better to convert the current usages of menclose as a one off and document how the conversion can be done?

It would be nice to have an menclose CSS/polyfill ready for discussion, sure.
Indeed, wouldn't it be better to first achieve that and examine the result, so that we truly know if the MathML element is entirely overlapping today's CSS coverage?

In addition, CSS support over MathML Core currently does not have full browser interop (e.g. Firefox), so making a decision to drop menclose with the assumption MathML Core + CSS is "ready today" would also be somewhat inaccurate.

[NSoiffer]

There is a polyfill for menclose (including for all the optional arrows and RTL), although it makes use of JS to:

1. do some measuring
2. decide when to activate
3. fails for webkit and gecko due to lack of CSS support

You can see the rendering in your browser here
There remains the issue of accessibility as I mentioned in #245, although intent might be a solution for that.

[physikerwelt]

Rendering with FF, Safari, and Chromium.

The accessibilty question is even worse when we want to support both menclose and the CSS solution. Overall, my feeling is the more different elements there are the more difficult it will be to develop AT technology.

I think we can be a bit more bold and describe what we would want to achieve, even if there are rendering problems with several browsers. On this level, it seems to me that it would better to advocate for fixing the CSS problem instead of adding additional elements to MathML (core).