MathML-Core meeting, Monday August 27 Agenda

[bkardell]

• Vertical Alignment of delimiters #205 
• Expose height/depth info #38
• U+002D HYPHEN-MINUS in operators #70
• Adjusted height & depth of elements moved via voffset #203
• Rename OverShift and UnderShift for munder/mover/munderover layout #121
• min-width for #202

[dginev]

Bookkeeping my (@dginev) minor action item from the meeting:

• Suggest minor clarifying comments in the Core text about the relationship between min-height, max-height, min-width, max-width CSS properties (which resize the containing block) and the minsize and maxsize MathML attribute (which resize stretchy content).

[bkardell]

minutes

08/28/2023 MathML Core Meeting

Attendees

• Brian Kardell
• Louis Maher
• Bruce Miller
• Neil Soiffer
• Dayan Ginev

Regrets

Agenda Items

Announcements/Updates

Issues

Vertical Alignment of delimiters #205

Ronkok wrote: There is a current problem with 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.

BM: For Chrome and WebKit, I didn't realize that a parenthesis should be stretchy by default.

NS: Chromium doesn't stretch parentheses by default.

BK: The issue is not that it does not stretch, but the alignment is wrong.

BM: But it looks as if the reason it's not making that adjustment is that it's not treating it as stretchy.

NS: So, I am seeing it stretching by default.

BK: The problem is that they do not need an adjustment to the vertical alignment, but the alignment has been changed anyway.

BM: The parentheses are too high.

BM: They may not need to stretch, but they still need to do the alignment as if they were stretching.

NS: If someone put stretch equals false, I don't think I'd expect it to
not aligned properly.

BM: That is a separate issue.

BK: Regardless of whether you stretch it, you have to align it.

NS: Some changes may affect section3.2.4.3. Lay out of operators.

NS: I don't think his proposed change is right. I'm not a hundred percent sure what the right way to change it is. I would comment saying here's a suggestion.

ACTION BM should further investigate this issue.

Expose height/depth info #38

NS: Having written a bunch of "polyfills" for MathML, there were three pieces of missing functionality that required hacks to implement: find the height/depth
of an element, convert a CSS length value to pixels (e.g., '3em'), and clone an element including its shadow root. The latter two issues are not specific to MathML, but MathML is somewhat unique in defining and using an element's height above the baseline and depth below the baseline.
Rather than having to rely on a hack, MathML elements should provide a method to get this information. This could be an extension of getBoundingClientRect that adds baseline info or depth (since height above baseline is easily computed from that) or it could be an entirely new method that returns height/depth/width.
info (the latter often being useful when doing computations involving box dimensions.

BK put issue 38 on the agenda because there were new comments, and it was not closed.

BK does not remember if we did something in CSS regarding this issue.

BK: We believe this belongs to CSS and we should give them an issue.

ACTION BK will make a CSS issue out of our issue 38 after talking to Dylan.

U+002D HYPHEN-MINUS in operators #70

Fred Wang commented: U+002D HYPHEN-MINUS is too short, so MathML browser implementations render it as U+2212 MINUS SIGN. Do we want to standardize this workaround?
I'd prefer not, but I guess the proper way to do it would be via a new text-transform value for mo.
If not, tools should generate the proper code point instead and we can write a polyfill for that.

BK: Believes that issue 70 is closable. Has the work been done?

BK: Is there a test? He does not know.

BK brought up the tests.

BK: I noticed that like many things, the lack of tests boils down to CSS related incompatibilities.

NS: Every year Interop meets to see how to bring web implementations closer together.

NS: Is there a startup time when we can lobby for math?

BK: It will be via https://github.com/web-platform-tests/interop/issues but it has not started yet.

BK: I think I will say that we are very likely to face the same thing that we faced last year: that math is Noone's priority.

BK: There are about a thousand backlogged projects, of which only about ten get worked on each year.
About a hundred new projects are proposed each year.

BK: Many other things are more popular than math because they bring in money.

BK feels that he can not argue too strongly for math.

NS: Every year the math projects do not get worked on. Someone should put in effort to fix the math problems.

BK: No resolution on issue 70. If we make or find a test, someone must agree that the test is valid. Someone must follow this issue.

[Adjusted height & depth

of elements moved via voffset #203](#203)

ronkok commented: The element has a voffset attribute, which enables one to shift the vertical alignment of an element. However, the MathML-Core specification
makes no mention of what happens to the height and depth of an element that is so shifted.
In practice, neither Chromium nor Gecko currently changes the height or depth of an element that is shifted via voffset. In MathML 3.0, one could manually
adjust the height and depth via attribute adjustments such as height="+6pt". MathML core does not have such a ± adjustment.
Some way is needed to make that adjustment of height and depth. Otherwise, one will see elements impinging on fraction bars, radical bars, and the like.
Currently in Chromium, one can apply CSS padding and that will increase the height or the depth of the element, depending on whether the padding is applied
to the top or the bottom of the element. Gecko does not behave this way. So, I know of no way to currently write an adjustment to height and depth that will run correctly in both browsers.
Is the padding hack a valid way to address this dilemma? Will it continue to run in future versions of Chromium and perhaps the other browsers? Should
this hack be explicitly written into the MathML Core specification?
Or will some other means of height adjustment become part of MathML-Core? Perhaps a return of the ± notation?

BK: The mismatch between Chromium and Gecko is Wrong.

NS: The problem is that Gecko does not use CSS. This is a big problem because we cannot have CSS doing things because things have not been updated.

NS: If more tests were added with more failures, would that help math's priority to get worked on?

BK: Chrome is correct.

NS: One suggestion is for Ron to add more platform tests.

NS: This is a bug, and we need to get some tests written on it.

ACTION NS: will reply to Ron about this and ask him to add platform tests for the case that Chrome is correct.

BK: I am not sure how we test for some of these CSS features.

BK: When you test CSS things, they should work everywhere.

BK: wonders if there is one massive test which can test everything?

NS: Writing tests is under appreciated.

ACTION BK will look into the test situation also. He will Look into where there is some existing test. On the CSS side of things, there could be tests without MathML.

BK: It should be easy to add MathML to these tests.

Rename OverShift and UnderShift for munder/mover/munderover layout #121

Fred Wang commented:
Shifts are from the baseline in OpenType MATH (see
w3c/mathml#123)
We should instead use "OverRise" and "UnderDrop" as in the corresponding parameters.

BK: It is on the agenda because it got more recent attention from Ron. Looking for feedback from Microsoft. MoS does not work at Microsoft anymore.

NS: Fred needs to respond to this. Ron has added more stuff and Fred needs to look at Ron's suggestions.

ACTION BK will follow up with Fred on issue 121.

min-width for #202

Ronkok commented: Currently in MathML-Core, one can set a width on an element, and I believe, only on an element. There seems to be no way to set a min-width.
on any MathML element, or otherwise.
This makes it difficult to emulate the behavior of LaTeX extensible arrows, all of which have a minimum width. This issue proposes to add a min-width to the specification of the element.

NS: Can you just put a minsize on the arrow?

DG: Actually, I was waiting for an opportunity to break in and discuss the first issue we considered which was issue 205, about minsize and maxsize.

DG: When Ron first opened the issue, he actually misspelled the attribute and he used the dash. So, he did min dash size and max dash size and that threw me off and I immediately went to look at min height and max height thinking he misspelled something in CSS.
But no, MathML has minsize and maxsize which are not oriented to an access, and I think you can use them for both vertical and horizontal stretching for the arrows.

DG: But there's min height and max height as well in CSS. And I kind of wonder if you have a stretch equals true construct which has min height and max height in CSS sets.

NS: would minwidth affect the stretchiness of arrows?

NS: If you had "A right arrow B" and you set minwidth to 200 pixels on that, NS said you would affect only the minimum width of the bounding box and not of the arrow.

DG: The names are really close. So, the reason for the confusion is min size and max size are really not specific to stretch.

DG: one stretches the content and one stretches the container.

NS: Do we have an answer for Ron?

BK: I do not know.

NS: What his issue proposes is to add a min with to the specification of the mpadded element.

BM Do things horizontally or vertically or both.

ACTION Ron is asking for a feature that already exists. NS will write back.
And so, my answer is you can say min size on the arrow and that's how you emulate the behavior. NS: will ask Ron for more clarification .

After the meeting, NS wrote:

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:

block quote
list of 1 items
4. If the operator has the
Symmetric property then set the target sizes as ascent and descent to Ascent and descent respectively.

DG: We should describe this in MathML core.

I think there's a lot more places where we can clearly state the CSS interop or lack thereof in MathML Core.

we can say that minsize can be used everywhere.

DG: So just clearly same min with canbe used anywhere.

NS: Were in the spec do we need to add language?

** ACTION** DG: will look into the spec to see where changes are needed and say what are the changes.

DG wrote minor action item from the meeting:

• Suggest minor clarifying comments in the Core text about the relationship between min-height, max-height, min-width, max-width CSS properties (which
resize the containing block) and the minsize and maxsize MathML attribute (which resize stretchy content).

ACTION BK will email the list to say when interop opens.

BK does not want to submit the request for math changes.

NS will submit the requested math changes. He submitted some stuff last year.

DG: Neil, if you wanted to have this horizontal arrow with a min size of 200 pixels but you didn't want it to stretch. Isn't that the problem? Because we have to do stretch equals true for the min size to take effect or did I misunderstand that.

NS: Let's just say the min size is 10 pixels and you're saying I want it to be 200, then it must stretch.

DG: It's nominally stretching even if it's not doing anything. So, if the min size is smaller than the usual size, for example, it won't do anything, right?

NS: Some glyphs do not stretch.

BK will be back for the September 25, 2023, core meeting.

NS: we do have a math meeting that week.

in TPAC.

Other people from Igalia will be there.

---