Minutes: MathML Full meeting 3 July, 2025

Louis was away, so the minutes are not up to their normal standards. There
is a lighted edited AI summary at the end.
Attendees:

   - Neil Soiffer
   - David Carlisle
   - Bruce Miller
   - Deyan Ginev
   - Moritz Schubotz
   - Murray Sargent
   - Bert Bos

Regrets

   - Paul Libbrecht
   - Louis Maher

Agenda1. Announcements/Updates/Progress reports

Open Collective work over the last half year on compatibility:
https://opencollective.com/mathml-core-support/updates/h2-2024-updates
2. There are 9 open issues with the "needs spec update" label.
<https://github.com/w3c/mathml/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22need%20specification%20update%22>

Review issues and see who feels like they can contribute. From the last
meeting, we discussed the following:

No one did work on the following last week:

   -

   *ACTION:* DC will handle Remove alignmentscope from MathML 4 spec issue
   535 <https://github.com/w3c/mathml/issues/535>
   -

   *ACTION:* bring up nested math in token elements issue 522
   <https://github.com/w3c/mathml/issues/522> in the next meeting.

DC: nested math is already allowed, but would like to call out that special
case.

DG: it can always be flattened, for example by splitting the mtext apart
and surfacing the children of the math.

DG: We should allow it.

DC: let's mention it in chapter 7 (where HTML extensions are discussed) so
it is an extension and hence not promoted.

DC and DG: some common uses are structured text with math and links in
core. Also images since mglyph is going away.

In many cases, the nesting can be flattened so the implementation doesn't
have to actually worry about an extension if one knows about about font
changes, anchor/links, etc. Perhaps done via a polyfill.

*ACTION* DG will make a PR.

   -

   *ACTION:* DC will handle XSD not allowing (semantics)-element as child
   of (apply)-element: issue 498 <https://github.com/w3c/mathml/issues/498>.
   -

   *ACTION:* DG: Find out what we agreed to do about Intent Properties:
   ordering & references · Issue #449
   <https://github.com/w3c/mathml/issues/449>.
   -

   *ACTION:* NS: move this to the core meeting Spec should specify what
   char to use for accents/lines · Issue #247
   <https://github.com/w3c/mathml/issues/247>.

Closed #180 (no longer relevant)

DC: will use words for schema for case-insensitivity for #178. DG will
finish off making the changes in the spec.

Discussion about mstyle (#1). Everyone agreed that only
displaystyle/scriptlevel seem to be used on mstyle in practice. In core,
mstyle exists, but it is the same as mrow. displaystyle/scriptlevel are
global attributes and are accepted on all elements. MathML 4 says in 3.1.9,
that MathML 4 accepts all the global attrs in core, and that all elements
accept the global attrs.

What we need to do is carefully read the MathML 4 to make sure that the
above is actually true in the spec for the global attrs.

One thing that clearly needs to happen is that the DecimalPoint attr gets
removed from mstyle's attr description.
3 WPT for math

Collect a list of problems people have encountered as a first step and
check them off when there is a WPT?

Consensus that we should do this and it should be in core. Hopefully
someone starts to write the tests and checks them off when they do.

==============

Next week we should start with #449.

MS will add an issue for RoundHand, Chancery, and Isolated about
mathvariants.



*AI Meeting summary for Math WG (2025-07-03)*

Quick recap

The meeting focused on discussing and resolving various issues related to
MathML specifications, including attribute case sensitivity, the mstyle
element, and allowed attributes on presentation elements. The group also
explored the possibility of allowing nested math elements within token
elements and embedding HTML in MathML, considering potential implementation
challenges and use cases. Finally, they planned to create a list of
rendering problems requiring web platform tests and discussed future steps
for addressing additional issues in upcoming meetings.
Next steps

   - David: Create a PR to add nested math elements as a native extension
   in Chapter 7 of the MathML spec
   - David: Review the MathML spec from beginning to end to ensure
   attribute descriptions for presentation elements align with core global
   attributes
   - David: Remove decimal point attribute from mstyle in the MathML spec
   - Neil: Create an issue in Core repo for tracking rendering problems
   that need web platform tests
   - Murray: Create an issue for discussing the addition of new math
   variant names
   - Murray: Add RoundHand, Chancery, and isolated font variants to the
   polyfill implementation
   - Deyan: Complete the case-sensitive attribute implementation as
   self-assigned on April 3rd

Summary MathML Specification Issues Review

Neil and David discuss several open issues related to MathML
specifications. They closed the issue about decimal point value definition,
as they've decided not to support it on malignmark and maligngroup
elements. They also reviewed the status of tagged PDF output in various TeX
distributions, noting that the current TeXLive version includes tagging
from last year but doesn't yet support math structure elements. Lastly,
they address the issue of making MathML attributes ASCII case-insensitive,
which Deyan has volunteered to modify the spec but hasn't completed yet.
MathML Case Sensitivity Discussion

David discussed the issue of case sensitivity in MathML attributes, noting
that HTML attributes are case-insensitive. He suggests either modifying the
schema or simply stating that attribute values should be lowercase before
validation. Neil and others acknowledge they don't use schemas regularly.
Deyan points out that HTML specifies case-insensitive comparisons rather
than attributes themselves. David agrees to leave the actual specification
as is but may add a note about lowercasing elements and attributes for good
practice.
MathML Display Style Element Discussion

Neil and David discuss the mstyle element in MathML. They note that decimal
point is still in the spec for mstyle but only affects stack elements, and
they agree it could be removed. They consider the differences between
mstyle and  in core and full, with mstyle allowing inheritance while core
does not. The group discusses usage of mstyle, with Neil noting it's
commonly used to set display style to block or inline. Bruce and Moritz
confirm they generate mstyle mainly for displaystyle purposes. Murray
mentions it's useful for fractions. The discussion touches on which
elements allow the displaystyle attribute, with David finding that only
mstyle explicitly allows it, though other elements can implicitly change
it. They consider aligning the full MathML spec with core MathML, which
allows displaystyle and scriptlevel attributes more broadly. The group
debates whether to restrict displaystyle to only mstyle in full MathML or
allow it more widely for consistency with core MathML and browser behavior.
MathML Attribute Consistency Discussion

David and Neil discuss the attributes allowed on MathML presentation
elements. They agree that all global attributes from the Core specification
should be allowed on all presentation elements, which aligns with the
current MathML 4 specification. However, they realize that some parts of
the spec may still reflect MathML 3 and need to be updated for consistency.
They identify that line-breaking attributes are still specific to certain
elements and not part of Core. The group decides to review the entire
specification to ensure all attribute descriptions match this approach.
They also agree to remove the decimal point attribute from the spec.
Web Platform Test Planning

Neil proposes creating a list of rendering problems that need web platform
tests, which the group agrees is a good idea. He plans to create an issue
in the core repository with checkboxes for each problem, allowing people to
add to it and mark off completed tests. The group then decides to discuss
nested math in the remaining time of the meeting.
MathML Token Element Extensions

David proposes allowing math elements as children of token elements in
MathML, which would be useful for pure mathematical contexts like embedding
in PDFs. Neil inquires about potential drawbacks, and David mentions it
could break tools like MathCAT that assume token elements contain only
text. They discuss how to handle this in specifications and tools, with
David suggesting it could be marked as an optional feature. Neil agrees
that supporting nested MathML is more likely than arbitrary HTML. They
consider adding this as an extension to the MathML specification and search
for the appropriate section to include it.
MathML Text Support Extension Discussion

David proposes to add support for text within math elements as an optional
extension in Chapter 7 of the specification, rather than changing the core
requirements. This approach would allow systems to support MathML without
necessarily supporting this feature. Neil and Deyan express agreement with
making the feature more obscure and allowing it without encouraging its
use. The group discusses potential implementation challenges and semantic
implications of this feature, with Murray suggesting that flattening the
structure might be a viable solution in some cases.
HTML in MathML Embedding Discussion

The group discusses the need for embedding HTML in MathML, particularly for
formatting and linking. David explains that it's common for inline HTML to
be used within mtext elements for these purposes. Murray and Neil debate
the best approach for handling this, with Murray suggesting coming out of
MText to add formatting. The discussion then shifts to common use cases,
including structured text within structured text, links, and CSS. Neil
proposes that in many cases, the nesting could be flattened for simpler
implementation. The meeting concludes with plans to create a pull request
for further discussion and to address additional issues in the next
meeting, including intent testing and potentially adding new math variant
names.