Minutes: MathML Core meeting: 27 Oct, 2025

 Attendees

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Eri Pérez
   - Deyan Ginev
   - Paul Libbrecht
   - Murray Sargent

<https://cryptpad.fr/#cp-md-0-regrets>Regrets

   - Brian Kardell

<https://cryptpad.fr/#cp-md-0-action-items>Action Items
<https://cryptpad.fr/#cp-md-0-2-action-items-from-last-meeting->2. Action
Items from last meeting:
<https://cryptpad.fr/#cp-md-0-browser-vendor-preference-on-lt-a-gt-vs-mrow-someone-from-mozilla-and-someone-from-google-people-gave-a-thumbs-up-to-using-lt-a-gt->Browser
vendor preference on <a> vs mrow? (Someone from Mozilla and someone from
Google people gave a thumbs up to using <a>)

*ACTION:* EP: I am not sure about the WebKit, I can ask there.

*ACTION:* NS: So, it seems like we are moving towards <a>, since that seems
to be what the browser vendors are willing to do. We will need to change
the MathML full spec to mention that, though.
<https://cryptpad.fr/#cp-md-0-3-a-href-https-github-com-w3c-mathml-core-issues-165-trimming-of-whitespace-in-attribute-165-a->3.
Trimming of whitespace in attribute #165
<https://github.com/w3c/mathml-core/issues/165>

*ACTION:* NS: On the call today, we agreed that the length points off to
CSS and that all that needs to be done is to add some words about Boolean
not allowing whitespace.
<https://cryptpad.fr/#cp-md-0-4-a-href-https-github-com-w3c-mathml-core-issues-272-simplify-whitespace-collapsing-trimming-for-text-nodes-support-in-core-272-a->4.
Simplify whitespace collapsing/trimming for text nodes, Support in Core?
#272 <https://github.com/w3c/mathml-core/issues/272>

*CONSENSUS:* NS: The consensus at the meeting today is that whitespace
trimming is highly desirable. Eri says that this is easy to do in WebKit
(he just removed it) and it is already that way in Firefox. He is going to
investigate how hard it would be to do it in Chromium. If it is not too
difficult, then the group felt it should be done. In addition to the
implementation change, this would necessitate some spec changes. However, a
polyfill would no longer be needed.
<https://cryptpad.fr/#cp-md-0-5-a-href-https-github-com-w3c-mathml-core-issues-125-mtable-support-125-a->5.
mtable support #125 <https://github.com/w3c/mathml-core/issues/125>

*CONSENSUS:* At the meeting today, the consensus was that getting alignment
to work via CSS is hard. This is true for both baseline vertical alignment
with "tall" items and dealing with horizontal alignment that differs by
column. The latter is complicated by the lack of decimal alignment in CSS.
This argues for some support in MathML. However, the group recognizes that
any implementation would not be simple and would jeopardize getting Core to
PR, so we agreed it should be moved to level 2.
<https://cryptpad.fr/#cp-md-0-6-a-href-https-github-com-w3c-mathml-core-issues-273-css-interoperability-with-vertical-align-273-a->6.
CSS interoperability with vertical-align #273
<https://github.com/w3c/mathml-core/issues/273>

*ACTION:* NS: This just needs a test, that is all.
<https://cryptpad.fr/#cp-md-0-7-a-href-https-github-com-w3c-mathml-core-issues-286-operator-spacing-adjacent-to-lt-mtext-gt-286-a->7.
Operator spacing adjacent to <mtext> #286
<https://github.com/w3c/mathml-core/issues/286>

*ACTION:* MuS: This is just adjacent to the current subject, but I did
notice that the native rendering on Chromium does not handle Unicode spaces
correctly, whereas MathJax does. NS: You should add an issue to core about
this.

*ACTION:* NS wrote: We did not come to a conclusion, but there did seem to
be movement towards removing mtext from the list of space-like elements
because it can contain non-space content that is mathematically meaningful
("not", "if", ...) and also because one can put arbitrary HTML inside of
it. We may discuss it in the full meeting.
<https://cryptpad.fr/#cp-md-0-agenda-items>Agenda Items
<https://cryptpad.fr/#cp-md-0-1-announcements-updates>1.
Announcements/Updates
<https://cryptpad.fr/#cp-md-1-2-action-items-from-last-meeting->2. Action
Items from last meeting:
<https://cryptpad.fr/#cp-md-0-scribing-irc-a-href-https-www-w3-org-guide-meetings-zakim-html-should-we-just-use-zakim-a->Scribing
/ IRC – should we just use Zakim
<https://www.w3.org/guide/meetings/zakim.html>?

LM: No updates.
<https://cryptpad.fr/#cp-md-1-browser-vendor-preference-on-lt-a-gt-vs-mrow-someone-from-mozilla-and-someone-from-google-people-gave-a-thumbs-up-to-using-lt-a-gt->Browser
vendor preference on <a> vs mrow? (Someone from Mozilla and someone from
Google people gave a thumbs up to using <a>)

*ACTION:* EP: I am not sure about the WebKit, I can ask there.

*ACTION:* NS: So, it seems like we are moving towards <a>, since that seems
to be what the browser vendors are willing to do. We will need to change
the MathML full spec to mention that, though.
<https://cryptpad.fr/#cp-md-0-text-in-mrow-anything-blocking-a-pr->Text in
mrow: anything blocking a PR?

NS: Text inside mrow: I think, Eri, you were going to do PR? Is there some
issue that came up?

EP: There were a few concerns that Fred raised. EP is talking to browser
providers.

EP: I am not too sure who to contact on Chromium, and I do not know if you
have any suggestions there.

EP: I would like to make sure that the browser vendors, especially Chromium
and WebKit, are on board with this change.
<https://cryptpad.fr/#cp-md-1-3-a-href-https-github-com-w3c-mathml-core-issues-165-trimming-of-whitespace-in-attribute-165-a->3.
Trimming of whitespace in attribute #165
<https://github.com/w3c/mathml-core/issues/165>

NS: I would have thought that there are some standards here, there are not.
Every attribute is handled differently.

EP: In HTML, it is allowed to have white space.

MuS: It does not seem that an attribute value should have any trailing Or
leading white space. It would be cleaner not to have it.

From Eri to everyone: HTML Standard
<https://html.spec.whatwg.org/multipage/syntax.html#attributes-2>

PL: CSS is always trimmed.

NS: We currently say nothing.

*ACTION:* NS: On the call today, we agreed that the length points off to
CSS and that all that needs to be done is to add some words about Boolean
not allowing whitespace.
<https://cryptpad.fr/#cp-md-1-4-a-href-https-github-com-w3c-mathml-core-issues-272-simplify-whitespace-collapsing-trimming-for-text-nodes-support-in-core-272-a->4.
Simplify whitespace collapsing/trimming for text nodes, Support in Core?
#272 <https://github.com/w3c/mathml-core/issues/272>

*CONSENSUS:* NS: The consensus at the meeting today is that whitespace
trimming is highly desirable. Eri says that this is easy to do in WebKit
(he just removed it) and it is already that way in Firefox. He is going to
investigate how hard it would be to do it in Chromium. If it is not too
difficult, then the group felt it should be done. In addition to the
implementation change, this would necessitate some spec changes. However, a
polyfill would no longer be needed.
<https://cryptpad.fr/#cp-md-1-5-a-href-https-github-com-w3c-mathml-core-issues-125-mtable-support-125-a->5.
mtable support #125 <https://github.com/w3c/mathml-core/issues/125>

NS: Core has little support for mtable.

DC: The lack of alignment is a pain.

NS: You should be using CSS to make a table look nice.

NS: I did write a polyfill.

NS: We should make this a core level two issue.

NS: Attributes on mtable need to be completely rethought and redone and, so
we closed this issue and say no we are not going to do mtables.

PL: I am wondering whether we are losing a competitive advantage to MathJax
by postponing this. I do not see a solution now.

PL: It could be a reason to adopt MathJax for some people that say, you
know, MathJax can do it, I need my tables.

*CONSENSUS:* At the meeting today, the consensus was that getting alignment
to work via CSS is really hard. This is true for both baseline vertical
alignment with "tall" items and dealing with horizontal alignment that
differs by column. The latter is complicated by the lack of decimal
alignment in CSS. This argues for some support in MathML. However, the
group recognizes that any implementation would not be simple and would
jeopardize getting Core to PR, so we agreed it should be moved to level 2.
<https://cryptpad.fr/#cp-md-1-6-a-href-https-github-com-w3c-mathml-core-issues-273-css-interoperability-with-vertical-align-273-a->6.
CSS interoperability with vertical-align #273
<https://github.com/w3c/mathml-core/issues/273>

*ACTION:* NS: This just needs a test, that is all.
<https://cryptpad.fr/#cp-md-1-7-a-href-https-github-com-w3c-mathml-core-issues-286-operator-spacing-adjacent-to-lt-mtext-gt-286-a->7.
Operator spacing adjacent to <mtext> #286
<https://github.com/w3c/mathml-core/issues/286>

NS: Is there anything we need to do to the spec or is it an implementation
bug?

*ACTION:* MuS: This is just adjacent to the current subject, but I did
notice that the native rendering on Chromium doesn't handle Unicode spaces
correctly, whereas MathJax does. NS: You should add an issue to core about
this.

DG wrote: I am a little concerned about behavior here. #286
<https://github.com/w3c/mathml-core/issues/286> discusses the space-like
details/confusion. Trimming behavior would further confuse matters. It
would be nice to have clarity in the text about the spacing subtleties of
mtext.

NS: So, Deyan, is your thought that we should remove mtext from this or is
your thought that trimming white space is a bad idea?

DG: My only thought is that doing them together is very confusing.

NS: I am having trouble seeing why removing them together is a problem.

DG: Does that sound predictable to you? That is very surprising behavior,
right? You have a space-like element, which implies its function is to pad,
and then you say, oh, we are going to trim some of the spaces.

*ACTION:* NS wrote: We did not come to a conclusion, but there did seem to
be movement towards removing mtext from the list of space-like elements
because it can contain non-space content that is mathematically meaningful
("not", "if", ...) and also because one can put arbitrary HTML inside of
it. We may discuss it in the full meeting.
<https://cryptpad.fr/#cp-md-0-zoom-meeting-summary-10-27-2025>Zoom Meeting
Summary 10/27/2025 <https://cryptpad.fr/#cp-md-0-summary>Summary

The team discussed various technical issues including browser vendor
support for <a> instead of mrow, text rendering inside mrow, and whitespace
trimming in attribute values. They also addressed challenges with MathML
implementation, particularly regarding mtable support and text trimming,
while acknowledging limitations in their current approach compared to
competitors like MathJax.
<https://cryptpad.fr/#cp-md-0-mrow-to-lt-a-gt-transition-discussion>Mrow to
<a> Transition Discussion

The team discussed moving towards using <a> instead of mrow based on
browser vendor support, with Mozilla and Google giving approval. David
noted that while the solution is imperfect, it is better to have something
than nothing, and they will need to update the MathML full spec to reflect
this change. Eri reported ongoing discussions with browser vendors about
text rendering inside mrow, particularly regarding anonymous nodes and CSS
child selectors, and is waiting for responses from WebKit and Chromium
teams. The team also briefly touched on whitespace trimming, with Neil
expressing uncertainty about the current spec's handling of attributes and
whitespace, inviting further discussion.
<https://cryptpad.fr/#cp-md-0-css-white-space-handling-discussion>CSS White
Space Handling Discussion

The team discussed handling white space in attribute values, focusing on
whether to trim or ignore it. They decided to follow the CSS specification,
which trims white space for length and percentage attributes but not for
others. For Boolean attributes, they agreed to add a note specifying that
white space is not trimmed. David mentioned he had several action items to
update the specification, and Neil proposed adding a few words about
Boolean attributes. The team also briefly touched on simplifying white
space collapsing for text nodes but did not reach a conclusion.
<https://cryptpad.fr/#cp-md-0-mathml-text-trimming-and-mtable-support>MathML
Text Trimming and mtable Support

The team discussed two key issues: text trimming and MathML and mtable
support. For text trimming, they agreed it should be implemented, though
Ari will first check the feasibility of the code changes, especially for
Chromium. They decided to label this as "Worth Trying" with Ari's
investigation as a condition. Regarding mtable support, they determined it
would be difficult to implement due to the lack of decimal alignment,
leading them to consider elevating this to Core Level 2.
<https://cryptpad.fr/#cp-md-0-addressing-mtable-and-equation-challenges>Addressing
mtable and Equation Challenges

The team discussed issues with mtable attributes and decided to move the
related problem to level 2, acknowledging that a complete solution might
not be feasible within the current timeframe. They also addressed vertical
alignment problems in equations, noting that while a solution exists, it
may not be practical given the implementation challenges. They concluded
that the best approach might be to acknowledge the limitations of their
current implementation and focus on core functionality, while leaving more
complex features for future development.
<https://cryptpad.fr/#cp-md-0-mathml-space-handling-implementation-bug>MathML
Space Handling Implementation Bug

The team discussed an implementation bug related to space handling in
MathML, where spaces before operators were being treated differently than
specified in the spec. David and Neil agreed that the spec was correct and
the issue likely stemmed from incorrect implementation rather than needing
a spec change. Murray raised a separate concern about Chromium's incorrect
handling of Unicode spaces in native rendering compared to MathJax, which
Neil suggested should be reported as a Chrome implementation bug rather
than a spec issue. Deyan explained that the mtext specification allows for
non-breaking spaces and other Unicode characters to be used as separators
within text elements, which could be affected by trimming, potentially
breaking the layout.

The team discussed the behavior of mtext space-like elements and whether to
remove them or trim white space. Deyan and David debated the definition and
functionality of mtext with Deyan arguing it should be considered
space-like due to its non-breaking space characters, while David suggested
it does not fit the space-like description. The team agreed to postpone
further discussion of this issue to a full meeting, as it may be a MathML
problem requiring broader consideration.