MathML-Core Meeting Minutes from January 31_ 2022

01/31/2022 MathML Core Meeting

 Attendees

* Bert Bos
* Deyan Ginev
* Brian Kardell
* Louis Maher
* Bruce Miller
* Murray Sargent
* Patrick Ion
* Neil Soiffer
* Moritz Schubotz
* Oriol Brufau
* David Carlisle

 Regrets

* Manuel Rego
* Stephen Watt
* Fred Wang

 Announcements

Oriol Brufau will represent Igalia at our meetings instead of Manuel Rego.

 Can we resolve/close?

 stable and compact operator dictionary

https://github.com/w3c/mathml-core/issues/104

Stable and compact operator dictionary #104 (Can we close it?)

Resolution close this issue. with a new issue Proposed Resolution: To close this issue adding a comment to open a new issue for Step 4, if anyone feels
that's needed.

 Add security considerations section Agenda

add security considerations section #50
https://github.com/w3c/mathml-core/issues/50

(Can we close it?)

Resolved that this is dealt with in core, move this issue back to MathML full where it is still relevant.

DC: has move this back to MathML full.

 Expose height/depth info Agenda level 2

Expose height/depth info #38
https://github.com/w3c/mathml-core/issues/38

BK: Issue Number 38 is tagged for L2.

NS: When writing a polyfill, it is useful to have the height and depth of a character.

NS wants core to expose this implementation. Maybe in a CSS feature. It would be Very useful for math rendering.

Action: See if there are already open CSS issues for this issue. OB and BK will look for these CSS issues.

Resolution: Inform the CSS WG of this need then close this issue (38). When closed, Link this to the CSS Issue.

 The hard ones

 Include mo@accent attribute into MathML Core? Agenda

Include mo@accent attribute into MathML Core? #52
https://github.com/w3c/mathml-core/issues/52

Fred Wang: mo@accent duplicates what is provided by munderover's accent attribute and violates the CSS logic of having properties depending on parents
not on arbitrary descendants. As I said elsewhere I think it should just be removed and not implemented in Chromium.

The two methods for rendering accents were shown by screen share.

NS: MathML 3 can say whether something is an accent on the operator itself and on the mover tag. Fred wants to ignore any setting on "mo" and only deal
with it on the mover. This would be a large change.

DG: This is a simple change in how the accent looks. MathJax never uses this attribute. It is using the defaults which work.

NS: Fred does not want to use the defaults.

MUS: will find out how word shows the accent if it goes in mover or mo.

DC: Should this go in level one?

BK: We will have an intent to be shipped in Chromium. We should decide if this is in level one.

DC: I would not delay a shipment to get this in.

NS: I checked MathType, and it uses accent on mover. Murray did the same for Word's editor and found the same. However, the WIRIS editor does not use accent
on mover.

MUS: Word will switch over to MUS's approach.

BK: How much will be heavily affected by this.

BK: How many sites will not be able to make the transition to spec 4 because of this issue?

DG: How Many sites will not use the MathML output and have MathJax fix it?

NS: will contact the MathJax team to see if they can use accent = true on mover.

MOS: MS Word puts the accent true on mover.

Proposed Resolution: Contact the MathJax team and see if they can generate accent=true on mover for some day in the future when there is a MathML-Core
output support. (Neil will take the action). If they are willing to do that (as they are ~95% of the output), then we will remove accent on the mo in the
spec as suggested in the issue. A secondary issue can be opened in full.

Resolution: If MathJax is willing to do this, then we will remove accent on the mo pe property and only allow it on mover.

 9U+002D HYPHEN-MINUS in operators Agenda

U+002D HYPHEN-MINUS in operators #70
https://github.com/w3c/mathml-core/issues/70

Fred Wang: 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: People do not generally write MathML.
Both Firefox and Safari do this conversion.

NS: This issue should not stop a product from shipping.

BK: The spec should say that ascii minus should be rendered as mathematical minus. Igalia should review this.

The group did not come to any conclusion on this issue.

BK: We have thirty-nine open issues. Ten are level two. Twelve are "needs tests".

BK: We have two pull requests for level 2. Pull requests for the MathML core.




Regards
Louis Maher
Phone: 713-444-7838
E-mail: ljmaher03@outlook.com