Vertical Alignment of <mo> delimiters

[ronkok]

I propose two edits to MathML-Core section 3.2.4.3 Layout of operators.

The first edit is shown below in bold.

2. If the operator has the stretchy property or has the minsize attribute:

There is a current problem with <mo> delimiters in both Chromium and WebKit. This problem affects a parenthesis which does not have stretchy="true" but has been up-sized with a minsize attribute. Such delimiters should be vertically aligned to be centered on the math axis. Both Chromium and WebKit fail to make that adjustment.

You can see an example if you navigate to the Temml Mozilla tests and scroll down to line 14. There are more examples in the Wikipedia tests, in lines 178 & 179.

I propose a second edit after the line which reads “Otherwise, the stretch axis of the operator is block. The following steps are performed.”

I propose to insert item 2 below.

2. If the size of in-flow children make it unnecessary to shape a stretchy glyph in the block direction, then fallback to the layout algorithm of 3.2.1.1 Layout of <mtext>.

This problem also occurs in both Chromium and WebKit. An example can be seen here. Those parentheses do not need to stretch, and they don’t. So far, so good. The problem is that they do not need an adjustment to their vertical alignment. But the alignment has been changed. They are placed too high.

My first proposal is related to Chromium Issue 1468676. My second proposal is related to Chromium Issue 1350167.

[davidcarlisle]

I don't think the first edit is needed, as minsize only applies to stretchy operators (which may implicitly have that property via the operator dictionary).

eg

https://www.w3.org/TR/MathML3/chapter3.html#presm.presatt says

minsize ... Specifies the minimum size of the operator when stretchy;

https://www.w3.org/TR/mathml-core/#operator-fence-separator-or-accent-mo

Finally the minsize and maxsize attributes add additional constraints over the stretch size.

[ronkok]

I don't think the first edit is needed, as minsize only applies to stretchy operators …

That’s a reasonable position. My aim was to eliminate ambiguity. If everyone agrees with David’s interpretation of the current specification, then the first edit is superfluous.

[brucemiller]

Is the underlying problem with the first chromium issue, that chromium does not set stretchy=true (from the operator dictionary)?

[ronkok]

The delimiters do change size when a minsize attribute has been set. Looking at it from the outside, that's as much as I know. Perhaps some internal switch is not properly flipped.

[NSoiffer]

We discussed this at the core meeting today. The feeling was that the problem is that the symmetric property isn't being respected.

So I would suggest that @ronkok's proposal be tweaked:

In 3.2.4.3, the second clause should be changed to (change is in bold):
2. If the operator has the stretchy property or has the symmetric property:

This change means that clause 4 of the "Otherwise" part kicks in and ascent and descent are set correctly:

4. If the operator has the symmetric property then set the target sizesTascent andTdescent toSascent andSdescent respectively...

[fred-wang]

I haven't checked things in details, but I agree with @davidcarlisle that per MathML full symmetric, maxsize, minsize only have effects when the operator is stretchy per https://w3c.github.io/mathml/spec.html#presm_mo_dict_attrs so I don't think the second clause "If the operator has the stretchy" should be modified to force handling symmetric, maxsize or minsize.

[davidcarlisle]

A related mo alignment issue is shown at
https://w3c.github.io/mathml-docs/intent-examples/#id-1-afbf0c9d54fa697fee15f8c64feda4b2
where chrome sets the ] far too low, I meant to report that at the chromium tracker but haven't done so yet.

firefox

chrome

[NSoiffer]

We discussed this again at the meeting today. The feeling is that since the MathML full spec says stretchy must be true for symmetric, min, and max attributes to have an effect, we should "stay the course" and not make a change. Making a change has the potential to break existing MathML usage (although we don't know how much, if any, would break). It is always possible to set stretchy and adjust min or max to prevent stretching the chars, so there is a work-around.

For the record: @dginev mentioned that CSS has a method to set min/max width/height. As noted in the call, this sets the bounding box min/max, not the min/max of a stretchy char. So there is no conflict between these attributes/properties.

@ronkok: we propose to close this issue. Do you object to that?

[ronkok]

@NSoiffer, Thank you for the follow-up. I agree completely with a decision to forego the first edit that I suggested in this issue.

But the original post also contains a second suggested edit to MathML-Core section 3.2.4.3:

I propose a second edit after the line which reads “Otherwise, the stretch axis of the operator is block. The following steps are performed.”

I propose to insert item 2 below.

If the size of in-flow children make it unnecessary to shape a stretchy glyph in the block direction, then fallback to the layout algorithm of 3.2.1.1 Layout of <mtext>.

That edit is still worthwhile. Its adoption would eliminate a vertical mis-placement of parentheses as shown here.

I think closing this issue would be premature until that suggestion is at least considered.

Perhaps you think it should be a separate, stand-alone issue. I would be happy to open one if you prefer.

[NSoiffer]

I was initially confused by your example because it looked good to me. Then I realized it was because I was viewing it in Firefox. In Chrome, it looks bad as you mentioned:

Chrome:
Firefox:

This should be part of the next meeting (January due to the holidays). Hopefully some people will chime in your suggested spec change.

[dginev]

I have been asked by arXiv to raise awareness of the impact of this issue, cross-referencing arXiv/html_feedback#354 (comment)