Minutes_ MathML Core meeting_ 26 January_ 2026

01/26/2026 MathML Core Meeting-core#308<https://github.com/w3c/mathml-core/issues/308>

Attendees

  *   Brian Kardell
  *   Louis Maher
  *   David Carlisle
  *   Eri Pazos
  *   Murray Sargent
  *   Bruce Miller
  *   Moritz Schubotz
  *   Deyan Ginev
  *   Paul Libbrecht
  *   Bert Bos
Regrets

Action Items
2. Interop Updates (Eri)
ACTION: EP will send his FOSDEM on interoperability and MathML Core<https://fosdem.org/2026/schedule/event/NJM3KB-mathml-core/> presentation to the math mailing list when it's posted.
4 Accent Characters (Neil and David)
ACTION: EP needs to write tests for core issue #70 U+002D HYPHEN-MINUS in <mo> operators<https://github.com/w3c/mathml-core/issues/70>.
6. Recent Issues
Supporting calc(100% + 0.333em) in the width attribute of <mpadded> #306<https://github.com/w3c/mathml-core/issues/306>
ACTION: DC will make a PR to say something that is true about how to increase width since Supporting calc(100% + 0.333em) in the width attribute of <mpadded> #306<https://github.com/w3c/mathml-core/issues/306> is wrong.

Agenda Items
1. Announcements/Updates

2. Interop Updates (Eri)

  *   math-depth and font-size: math now shipping in all browsers.
  *   font-family: math nearing shipping in Firefox.
  *   mathvariant implemented via text-transform, but not enabled by default on Firefox or WebKit due to concerns over breaking existing content. We have counters in place.
  *   Animation types for math-* CSS properties now shipping in all browsers.
  *   Giving a presentation this Saturday at FOSDEM on interoperability and MathML Core https://fosdem.org/2026/schedule/event/NJM3KB-mathml-core/.
BK to EP: Can you send your presentation to the math mailing list when it is posted?
EP: Yes.
ACTION: EP will send his FOSDEM on interoperability and MathML Core<https://fosdem.org/2026/schedule/event/NJM3KB-mathml-core/> presentation to the math mailing list when it's posted.
NS to EP: What will you be doing in the next couple of months?
EP: So, we are working on a few things. One of them is modernizing the code in Firefox, because it has a lot of legacy code, which is making it difficult to implement new things, or match the spec.
EP: We are also doing a few tweaks like small tests, like border or padding, or widths, or things like that, which are left over from all their implementations.
EP: One important thing that we want to do is handling position elements. This was already done in Chromium and WebKit, but Firefox is missing. It would be nice to also handle forbidding floats but that is a bit more complicated, because we would have to implement display math. It would be a wonderful thing to do, but it is more work, so let us see where we get with that.
EP: Also adding the right-to-left mirroring to WebKit which is the one that is missing for the RTLM font feature.
NS: We also have some critical things for interop such as the accented characters. Are those at all things you are going to be looking at?
EP: Fred and I were discussing the accent characters today to see what we can do about them.
PL: Did you say that you were not sure if display modes were going to be implemented? Many people consider display modes to be critical.
EP: Yes, I think it is our recent addition to MathML Core. There's display mode math. And it is block math, or inline math. The thing is, Firefox and Chrome do implement it, but Firefox and WebKit do not.
From Moritz Schubotz to everyone: "shipped in all browsers" is a good information, but it would be nice to track for each feature in which browser version. This has been implemented. To use a certain feature, we would want to wait until it is in the ESR FF release for example.
BK: This would all be in BCD data, so we do have that data.
3 Links Updates (Luke)

  *   Align anchor IDL across the platform? whatwg/html#12063<https://github.com/whatwg/html/issues/12063>
  *   Editorial: Refactor HTMLHyperlinkElementUtils whatwg/html#12066<https://github.com/whatwg/html/pull/12066>
BK: Luke is working on Pull requests to a couple of specs related to links.
NS: Is he working on different browsers? Was it only in the Chrome browser, or was it across Firefox and Safari?
BK: He is working on specifications.
MoS: Maybe this problem https://phabricator.wikimedia.org/T414289#11531304 is related?
4 Accent Characters (Neil and David)

  *   Spec should specify what char to use for accents/lines mathml#247<https://github.com/w3c/mathml/issues/247> (original issue)
  *   Intent of MathML-Core B.3 is unclear #309<https://github.com/w3c/mathml/issues/309> (issue)
  *   corrections to combining characters table #302<https://github.com/w3c/mathml-core/pull/302> (PR)
  *   add table of suggested chars for accents/lines mathml#552<https://github.com/w3c/mathml/pull/552> (related PR in full)
  *   Big table of accents characters and fonts<https://mathfonts.github.io/math-accents>
The core spec has appendix b.3 with two tables which are not explained. The two tables are virtually identical except for having their columns in a different order.
NS: And these tables are not mentioned in the spec.
DC: So, either we need to say which one to use, or what I wrote in the PR was that the renderer should pick, depending on the font, whichever one works.
DC: Which one works depends on font, browser, and character.
NS: Firefox pretty much normalizes stuff, so everything works there, which is great.
NS to EP: Can we allow both characters?
EP: It can be done. Perhaps we are already doing that. I would need a very definite table stating what characters to use.
DC: We should be able to tell people what works; however, we cannot do that.
NS: So Eri, are there other places where characters get remapped?
EP The minus sign.
NS: Did that get fixed in Chrome?
EP: I am not sure.
DC: I do not think it was fixed.
NS: I thought it had been resolved but not implemented.
DC: I will have to check the issue.
NS: It is listed as open, in core, #70 U+002D HYPHEN-MINUS in <mo> operators<https://github.com/w3c/mathml-core/issues/70>.
NS: It was assigned to BK.
NS We reiterated the need for core to support this based on the vast amount of MathML out there that uses the hyphen minus. We also verified that both Safari and Firefox still map it to 2212, so Chrome is out of step with those browsers.
NS: Both a spec update and a test need doing.
EP would decide what needs doing, and to write tests.
EP: We still need to write tests.
ACTION: EP needs to write tests for core issue #70 U+002D HYPHEN-MINUS in <mo> operators<https://github.com/w3c/mathml-core/issues/70>.
NS: What can we say about accents?
EP: As a first step, we can explore if it is feasible to have all accents map to one of them, and then we can figure out, Which character should we be rendering with which font.
BK: What do we do with pull 302?
After the meeting, for pull request 302<https://github.com/w3c/mathml-core/pull/302>, DC wrote:
As agreed on the MathML-core call 26th Jan, I deleted the paragraph describing browser behavior for now, so this just leaves the tables with corrected rows, and removing the table with re-ordered duplicate data.
The table has columns re-ordered to
<tr><th>Style</th><th colspan="2">non-combining</th><th colspan="2">Combining</th></tr></thead><tbody>
where "style" could perhaps be renamed but a value above refers to use in mover or the relevant slot in munderover and similarly below refers to use in munder or the relevant slot in munderover,
I think this can be merged, with the paragraph deleted it is purely editorial re-arrangement of the table data.
From Deyan Ginev to everyone: Is Unicode in any way receptive of "stretchy" standardization? To include accents also?
I recently ran into some comments: "The C, O, and F operators are stretchy. In addition, some binary operators such as U+002F are stretchy as noted in the descriptive comments. The classes are also useful in determining extra spacing around the operators as discussed in UTR #25."
From
https://www.unicode.org/Public/math/revision-15/MathClassEx-15.html
DG: I keep getting back to this notion that there is a standard that is defining properties on characters, which is Unicode, and there are still hints of stretchy being mentioned, at least? I keep running into it when I search for stuff. And this is one example in the chat with a link that's old, 2017, I think it is even earlier.
NS: DG's point is that some mention of some of these characters should be stretchy in the Unicode spec.
DG: Can we move in the direction where MathML Core outsources this concern, and we can add something to the spec saying, if you think this character should stretch, contacting the font support group is the thing to do?
DC: It has always been the MathML position that stretchiness is a font issue, but that leads to whether a character stretches is up to the font vendor.
NS: It would be nice for the spec to reference tr25 to determine whether a character stretches.
MuS: Stretchiness should be added to the operator dictionary.
5. issue 100 Simplification of the <semantics> element<https://github.com/w3c/mathml/issues/100>
PL: What Fred has decided is that it is going to be the first child who is hidden, or who is visible, and that's it. I want to know whether we have space to negotiate that. If we do not have, then we know how to implement the polyfill.
From Deyan Ginev to everyone: That issue could be transferred to MathML-core, fwiw.
PL: I mean, one has decided that only the first child is visible, and the other ones are hidden. So, there is an explicit mention of a CSS user agent entry that says everything that is a second child, or second, third, or anything of semantics is hidden.
PL: In that way, that works easily for Mathematical Core. I guess this is how it is implemented in all browsers. So, here we better backtrack and just say, okay, let us accept it, and then we will write the polyfill in accordance with that.
DC: It should be on the polyfill repo.
PL: So, we should move this issue to MathML polyfills.
NS Moved issue 100 Simplification of the <semantics> element<https://github.com/w3c/mathml/issues/100> to the polyfills repo.
6. Recent Issues
Supporting calc(100% + 0.333em) in the width attribute of <mpadded> #306<https://github.com/w3c/mathml-core/issues/306>
DC: So, we said that you could use calc to make an object .6 inch bigger. And I am sure at the time, which was years ago, I tested that and it worked. But it does not work now.
DC: Then there is this newish calc-size thing which does work.
DC: Calc-size only works in Chrome.
NS Is there a plan to have calc-size work elsewhere than only in chrome?
BK: It has support from Mozilla.
BK: It is coming but perhaps not fast.
DC: So, the current full spec is wrong, because it tells people you can do this, and you cannot.
BK: I guess the point is that it still will not work until Calc-size is supported everywhere.
DC: You do not need to use CSS; you can just use width. I mean, if you do not use a relative one, you must use the absolute value, and then you just must guess.
DG: You should double-check for browser bugs because I am looking at the code pen now, and the attribute width of mpadded Don't seem to be working for me in Chrome. If you put em's it works.
ACTION: DC will make a PR to say something that is true about how to increase width since Supporting calc(100% + 0.333em) in the width attribute of <mpadded> #306<https://github.com/w3c/mathml-core/issues/306> is wrong.
Zoom Core Meeting Summary For 1/26/2026
Summary
The team discussed agenda updates and reviewed progress on MathML implementations across browsers, including work on enabling MathVariant and addressing accent character display issues. They explored solutions for accent character specifications and discussed the need to clarify stretching rules in the Unicode properties database. The group also addressed various MathML Core issues, including incorrect specifications and potential browser bugs, while agreeing to track polyfill implementations in the dedicated repo.
Agenda and Interop Work Updates
The group agreed to skip Luke's part at the start and proceed with Erie giving an update on interop work.
MathML Browser Implementation Progress
Eri reported progress on MathML implementations across browsers:

  *   math-depth and font-size: math now shipping in all browsers.
  *   font-family: math nearing shipping in Firefox.
  *   mathvariant implemented via text-transform, but not enabled by default on Firefox or WebKit due to concerns over breaking existing content. We have counters in place.
  *   Animation types for math-* CSS properties now shipping in all browsers.
  *   Giving a presentation this Saturday at FOSDEM on interoperability and MathML Core https://fosdem.org/2026/schedule/event/NJM3KB-mathml-core/. Brian suggested sharing the presentation on the math mailing list. For upcoming tasks, Eri is focusing on modernizing Firefox code, addressing small tests, and handling positioned elements in math elements, while also working on right-to-left mirroring for WebKit. The team discussed accent characters display issues across browsers, with Eri confirming they are investigating solutions with Fred.
MathML Accent Character Specification Review
David raised concerns about inconsistencies in the specification of accent characters, particularly regarding two identical tables in core Appendix B.3 of the MathML specification. He proposed removing one table and allowing renderers to choose between equivalent characters based on the font. Ari suggested that character remapping could be a solution but emphasized the need for a clear table of equivalent characters. The group agreed that the current situation, where character display depends on the browser and font, is unsatisfactory and needs to be addressed. They discussed the possibility of documenting which characters work consistently across different implementations, or of specifying a single preferred character for each accent.
Accents Table Testing Discussion
The team discussed the need to write tests for their project and explored the feasibility of mapping all accents to one of them using a table. David presented a math accents table in Chrome, noting variations in stretchiness among different fonts. The group acknowledged the need to provide guidance to both browser and font implementers regarding which characters should stretch.
Table Cleanup and Unicode Standards
David discussed cleaning up a table by removing unnecessary text and rearranging columns to make it more understandable. He agreed to ping someone in the pull request to merge the changes without the extra text. Deyan raised a question about Unicode standards and stretchy characters, which David acknowledged as a recurring topic in previous discussions.
TR25 Unicode Stretching Rules
The team noted that while some characters are explicitly mentioned as stretchy, there is ambiguity about horizontal and vertical stretching, particularly for accents and certain binary operators. Murray suggested checking the operator dictionary data file for more information.
Polyfills Repo Issue Migration
The team discussed moving issue 100 related to M-Semantics and child visibility to the polyfills repo, which Neil completed immediately after the meeting. They agreed that the polyfill implementation should follow the browser behavior of hiding all but the first child, and David suggested that future polyfill issues should be tracked in the polyfills repo rather than MathML Core.
MathML Syntax Correction Discussion
David and the team discussed issue 306 in MathML Core, where the spec incorrectly states that a specific syntax for relative increments works, when in fact it does not. They agreed that David would create a pull request to address this, likely by removing the incorrect example and potentially clarifying the relationship between MathML and CSS. Deyan noted a potential browser bug affecting percentage values in Chrome, which David should investigate before making any changes.