Minutes_ MathML Core meeting_ 15 December_ 2025 (formatted)

12/15/2025 MathML Core Meeting-core#303<https://github.com/w3c/mathml-core/issues/303>

Attendees

  *   Brian Kardell
  *   Louis Maher
  *   David Carlisle
  *   Deyan Ginev
  *   Paul Libbrecht
  *   Eri Pérez
  *   Murray Sargent
  *   Neil Soiffer
Regrets
Action Items
2. The definition of "space-like"
ACTION NS should add a comment to issue 286 saying that the team agreed to standardize the empty selector definition to match CSS specifications.
4 Triage for #149 Whitespace should be trimmed in token elements<https://github.com/w3c/mathml-core/issues/149> - is this a task for CR or level 2 ? Does it need spec update, tests?
ACTION: BK asked the group to produce more test cases so we can decide how spaces should be treated. The cases should be added to issue 149. He will put in a comment in issue 149 about this.

Agenda Items
1. Announcements/Updates
2. The definition of "space-like"
Consider embellished operator / space-like definition and display: inline/block math, core issue #108<https://github.com/w3c/mathml-core/issues/108>
From David Carlisle to everyone: [pull request, for the full spec, to change the meaning of space-like by NSoiffer](https://github.com/w3c/mathml/pull/550
DG: It is based on the names of the elements says the spec
From Deyan to everyone: https://wpt.fyi/results/mathml/presentation-markup/spaces/space-like-001.html?label=master&label=experimental&aligned
NS: Looking at MathML full, but it also is about core.
DC: Mtext is spacelike. If it has text in it, it is not space-like. Mtext containing spaces is space like.
BK: If it contains an html comment, is it space like?
NS: Consider Operator spacing adjacent to core issue 286<https://github.com/w3c/mathml-core/issues/286>
From Deyan to everyone: definition is here:
https://w3c.github.io/mathml-core/#dfn-space-like
NS: There is the issue of what empty means for an mtext element.
NS: If there is only Ascii white space inside mtext, it is space like.
From Deyan to everyone: PR added to Full: "Mtext element that is empty or all of whose characters are Unicode spacing characters."
NS: Should we fix the core spec in relation to the comments found in issue 286?
From Brian Kardell to everyone: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:-moz-only-whitespace
From Deyan to everyone: "moz-space-like"
ACTION NS should add a comment to issue 286 saying that the team agreed to standardize the empty selector definition to match CSS specifications.
BK: The empty selector class has changed but it has not been implemented.
From Brian Kardell to everyone: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:empty
3 Massive inconsistencies with accent characters, including two tables in the core spec which are not referenced, not well explained, and (based on the inconsistencies) not used by the Chrome implementation.
issue 554 Intent of MathML-Core B.3 is unclear<https://github.com/w3c/mathml/issues/554>
NS: DC and I came up with this website to test math fonts<https://mathfonts.github.io/>
NS: What character should we use for an accent mark? Firefox does an excellent job. Chrome and Safari differ as to which character you should use.
BK: Are there two, or three, answers?
DC: You can choose anything you like because none of them work.
From Eri Perez to everyone: https://w3c.github.io/mathml-core/#combining-character-equivalences
DC and NS: Some characters stretch in some browsers and not in others.
DC: In section b.3 of the core spec, there are two tables which do not make any sense.
DC: These tables say what the combining and non-combining versions of the characters are. These tables are virtually identical except for two entries.
DC: This section should say something about what you are supposed to do.
NS: We do not know what characters work in which browsers.
NS said that Fred said it depends on the fonts; therefore, we cannot do anything.
DC: Some fonts are kind of frozen, and some fonts are maintained.
NS: We need to standardize this so that the browsers all do the same thing.
From Brian Kardell to everyone: https://toot.cafe/@bkardell/115725100050946366
DG: What is the relation between fonts and the MathML spec. Do the fonts have to follow the MathML spec?
From Deyan to everyone: What I was fishing for is a single "source of truth" for what should stretch and what can be an accent.
Then we fix it all in 1 place...
NS: you know, it is just seemingly almost random what works and what does not.
NS: I think the question for the group is, should the spec say which accent characters should be used; or, as David has in the spec, they should be normalized, and all of these should work.
MuS: Accept them all.
MuS: But then there should be some guidance to the font developers like, should they automatically have the same stretching property for all of them.
MuS: In office, we support most of them.
BK: I would like to talk to Ari some more about this on the implementation side and understand the incredible difference between the three implementations. I am sure it has a lot to do with history.
NS: From a user's point of view, in Firefox, everything works.
4 Triage for #149 Whitespace should be trimmed in token elements<https://github.com/w3c/mathml-core/issues/149> - is this a task for CR or level 2 ? Does it need spec update, tests?
DG: Is this a CR issue or a level 2 issue?
BK: If we know what should be done, and it is in core rendering, then we should just do it.
EP: We should do it.
From Murray to everyone: I added two rendering problems to Native MathML rendering problems<https://github.com/w3c/mathml-core/issues/229>.
NS: All the browsers should align on what they are doing. Is this hard to do?
EP: We should do what is expected and remove the white space.
BK: What happens when you set white-space normal as opposed to White-space pre? Do we respect the white-space CSS property?
NS: It is an important bug to fix.
From Brian Kardell to everyone: https://codepen.io/briankardell/pen/WbwBBXx
MuS brought up issue 229<https://github.com/w3c/mathml-core/issues/229> which discusses how Native MathML rendering differs from TeX/MathJax/Word in a number of ways. He said that Chromium does not know about Unicode spaces. in the 2000 block, there are a bunch of them. One of them is called a thin space. It renders as a thin space in MathJAX, but in Chromium it renders as a very wide space. We should support Unicode spaces.
DC: In MathML 3, we said that the renderer should ignore the white space at the beginning and end of the element.
ACTION: BK asked the group to produce more test cases so we can decide how spaces should be treated. The cases should be added to issue 149. He will put in a comment in issue 149 about this.
BK showed an example of an expression where the white-space property was set to normal then set to pre, and the spacing did not change.
DC White-space = normal will collapse several white spaces to one. White-space = pre will not do this.

Zoom Core Meeting Summary

Summary
The meeting focused on addressing various MathML rendering issues, particularly concerning whitespace handling and accent characters across different web browsers. The group discussed two key issues: one about trimming whitespace in token elements (issue 149) and another about handling whitespace in attributes (issue 165), ultimately deciding to focus on the former. They also explored discrepancies in how different browsers render accent characters, with Firefox providing the most consistent experience while Chrome and Safari showed significant variations. The team agreed to standardize the empty selector definition to match CSS specifications and to potentially add test cases to better define expected behaviors. David noted that font developers have been responsive to feedback about stretchy symbols, with some fonts being actively maintained to address rendering issues.

GitHub Core Rendering Issues Discussion

The team discussed two GitHub issues (149 and 165) related to trimming white spaces in token elements and attributes, respectively. Deyan clarified that these were Core issues, with 165 being easier to address than 149, which is MathML-specific. Brian suggested treating these as CR issues rather than level 2, emphasizing the importance of making progress and keeping alignment on core rendering tasks. The team agreed to proceed with addressing these issues as part of their ongoing work.

MathML White Space Alignment

The team discussed the handling of white space in MathML, with David explaining that traditionally MathML trims white space but he removed spaces from the spec. Neil and Eri agreed that browsers should align on their handling of white space, with Eri suggesting that spaces should be removed to make it easier for users. Brian raised a question about how MathML handles CSS whitespace properties, which David agreed to investigate after the call.

MathML Whitespace Rendering Issues

The team discussed issues with whitespace handling in MathML rendering, particularly how different browsers interpret spaces and line breaks. David explained that Mathematical renderer specifications require ignoring whitespace at the beginning and end of elements, with Firefox following this rule while Chrome does not. Murray raised concerns about Chromium's inability to recognize Unicode spaces, specifically the thin space (2009), which renders incorrectly as a wide space character. The team agreed this was an important bug to fix, with Brian suggesting support for Unicode spaces would be beneficial, though David noted that CSS cannot help with this issue due to the mathematical rule requiring single-character letters to be italic.

HTML Whitespace Rendering Discussion

The team discussed the rendering of whitespace in HTML, specifically comparing the behavior between "normal" and "pre" whitespace. They determined that the current implementation is consistent, as both renderings respect whitespace between token elements. While Deyan suggested testing with mtext and new lines to explore further nuances, the team agreed to address any additional questions at a later stage rather than delaying on a level 2 task. Neil asked for the action item, and Brian suggested writing tests or providing more explanation, but no final decision was made.

CSS MathML Integration Test Cases

The team discussed CSS integration issues with MathML, particularly focusing on space handling and white-space properties. Brian suggested creating test cases to better define the desired behavior and avoid special MathML handling that could deter engine updates. The group identified a typo in the white-space property name that needed to be fixed and agreed to attach the test cases to issue #149 rather than #165 which was about attribute trimming.

MathML Core Merge Review Issue

The team discussed pull request #550 and issue #286 in MathML Core, where they identified a problem with mtext being incorrectly considered space-like, which was merged but should be reversed. Brian raised concerns about the tests related to this change and questioned whether they align with the current specification. Neil and David clarified the issue, and Neil acknowledged that the definition of space-like elements is specific to MathML and not applicable to other elements. The team agreed to review and potentially reverse the merge if it does not match the intended behavior.

CSS Empty Element Definition Update

The group discussed the definition of empty elements in CSS, focusing on how whitespace and non-ASCII characters should be handled. They agreed to align with the empty pseudo-class definition from the CSS specification, which considers elements empty if they contain only whitespace, comments, or processing instructions. Brian noted that this change had already been made to the specification but was not yet implemented. The team decided to use this definition to update the MathML specification and potentially implement it in their own code, which Brian saw as an opportunity to demonstrate the broader impact of MathML beyond just mathematical content.

Browser Accent Character Standardization

The team discussed issues with accent characters across different web browsers, particularly focusing on the mathfonts.github.io options and browser inconsistencies. David explained that while there are multiple character options for accents like graves and tildes, there is a need to standardize which characters work in which browsers. Neil and David noted that while font developers have been actively maintaining and updating their fonts, the current documentation in the core spec contains conflicting information and needs clarification. The team agreed that standardizing the character options would help resolve browser inconsistencies and improve user experience.

MathML Font Stretching Standards Discussion

The group discussed the relationship between fonts and MathML specifications, particularly regarding accent characters and their stretching properties. David explained that while MathML prefers fonts to specify stretchable characters, it does not dictate which Unicode accent characters should be used, as this can vary between browsers. The team debated whether the specification should mandate specific accent characters or allow normalization, with Murray suggesting accepting all characters while providing guidance to font developers. Brian expressed interest in understanding the implementation differences between Firefox, WebKit, and Chrome, which David attributed to historical development practices and pre-Unicode math standards.