MathML-Core meeting, Monday Jan 31, 2022 Agenda

[bkardell]

Agenda items, feel free to reply to suggest more.

• Brief progress updates/plans?
• Can we resolve/close?
  • Stable and compact operator dictionary Stable and compact operator dictionary #104 (can we close it?)
  • Add security considerations section Agenda add security considerations section mathml#261 (can we close it?)
• Can we tag L2
  • Expose height/depth info Agenda  level-2  Expose height/depth info #38
• The hard ones
  • Include mo@accent attribute into MathML Core? Agenda Include mo@accent attribute into MathML Core? #52
  • 9U+002D HYPHEN-MINUS in operators Agenda U+002D HYPHEN-MINUS in <mo> operators #70

[bkardell]

minutes:

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 <mo> 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.