Minutes: MathML Full meeting, 7 April, 2025

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Murray Sargent
   - Bruce Miller
   - Paul Libbrecht
   - Deyan Ginev
   - Bert Bos

<https://cryptpad.fr/#cp-md-0-regrets>Regrets
<https://cryptpad.fr/#cp-md-0-action-items>action Items
<https://cryptpad.fr/#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

Upcoming meetings?

NS: Due to travel, NS will not be available for an intent meeting until
Thursday May 22, 2025.

*ACTION*: People are urged to work on polyfill writing and spec updating
during the meeting break. If people wish to have a meeting during this
time, they will write to DC, and DC will make a meeting announcement by the
Tuesday of the week in which the meeting will occur.

*ACTION*: NS: I believe that using <a> for links will continue to be
discussed in the core meeting at the end of April.

*ACTION*: DC will test to see if Safari supports HTML, in particular the
link inside of any of the leaf elements.

*ACTION*: NS: Our current charter ends October 13, 2025. Our Horizontal
review should start July 1. Our recharter writing should begin August 1.
<https://cryptpad.fr/#cp-md-0-agenda>Agenda
<https://cryptpad.fr/#cp-md-1-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

Upcoming meetings?

NS: Due to travel, NS will not be available for an intent meeting until
Thursday May 22, 2025.

*ACTION*: People are urged to work on polyfill writing and spec updating
during the meeting break. If people wish to have a meeting during this
time, they will write to DC, and DC will make a meeting announcement by the
Tuesday of the week in which the meeting will occur.

PL: Wiris does not support intent. If Wiris software is involved with
producing a document containing mathematics, intent items would be deleted.
Intent is not part of a finalized specification. We need to evangelize
intent.

PL: Wiris should not delete intent, however it should simply not mention
intent until our specification is released.

From Deyan Ginev to everyone: Paul's point: FidusWriter's latest release
supports MathML in its JATS export

DG: FidusWriter is the software that Paul and I discussed offline. They
have introduced in their latest release MathML exports for mathematics for
their JATS exports And that's a really good example of why "intent"s must
not be allowed until we are done. This is because JATS needs to adopt
MathML4 and use the MathML4 schema. If you add intent attributes, today,
it's an invalid document and I don't think you should be avoiding the JATS
spec just because we like our attributes. We need to finish the work here
and then it will swim upstream and next year maybe it will be accepted.

JATS stands for journal article tag suite.

NS: In CSS, if they are working on a new feature, and it is not yet part of
the candidate release but is only in the editor's draft, browsers will
start implementing it. You need implementations before a feature can have a
candidate release.

DC: I believe that we will have to support the <a> element for links
because there is no other alternative that would be implemented.

After the meeting, NS wrote: I heard back from David Cervone, one of the
developers of MathJax. Once we come up with a plan, they are willing to
support it. That includes allowing <a> everywhere. Currently <a> in MathML
results in an "Invalid MathML" error. Of course, a MathJax change in a
future version won't help with websites that aren't using the latest
version of MathJax.

*ACTION* NS: I believe that using <a> for links will continue to be
discussed in the core meeting at the end of April.

MuS: Word imports MathML using OMML to YAML. So we could entertain the
concept of coming up with an upgrade for that and then try to convince
people to accept it.

NS: Okay, so a word I'm pretty sure allows links inside of the math, right?

MuS: Yes.

NS: Does anybody know for sure, Do all the major browsers support HTML, in
particular the link inside of any of the leaf elements?

DC: All the Chrome-based ones do, and Firefox does. I don't know about
safari.

*ACTION*: DC will test to see if Safari supports HTML, in particular the
link inside of any of the leaf elements.
<https://cryptpad.fr/#cp-md-0-2-progress-on-spec-updates>2. Progress on
spec updates

There was no progress on spec updates.
<https://cryptpad.fr/#cp-md-0-3-polyfills-who-wants-to-write-some-of-them->3.
Polyfills: who wants to write some of them?

BM: Is there any documentation of what goes into these polyfills, and why
the pieces are necessary?

NS: I don't know if I actually wrote any.

NS: There is an observer, so when the page changes, the observer recognizes
there's a page change and runs the appropriate polyfills. Each polyfill
registers itself with a CSS selector and the function that should be called
when the selector returns an element.

NS reviewed the MathSize polyfill.

NS: At the end, if MathSize is small, it should call  TransformSmall. If
you see MathSize medium, you call transformMedium and so on. What does
Transform Medium do, well just sets an attribute on the element to be 100%,
and the other one is 75% and the other is 150%. It's just taking these
names and putting them into percentages.

NS reviewed how the Beveled attribute is set.

NS discussed the numerator and denominator alignment polyfill.

DC: If you are going to work on a polyfill, put a comment in the issue so
that two people do not work on the same polyfill.

NS then reviewed the five open issues with the "need polyfill" label
<https://github.com/w3c/mathml/issues?q=is%3Aopen%20label%3A%22need%20polyfill%22>

NS: Yeah, so I think most of them are Pretty easy. I think, David, the
Alignment polyfill is going to be One of the more complicated ones.

NS: It might help to look at the numerator and denominator alignment
polyfill.

DC: If we say that an issue can be solved by having a polyfill, then we
need to write the polyfill.

DC: I've hoped we're going to use just a CSS alignment because I don't
really want to measure the entire table and align it by hand.

PL: How do these things get tested?

NS: There is an index.html file which runs the polyfill tests.

DG: We have our charter expiring on October 13, 2025. What milestones do we
have to hit, and what happens after that.

BB: A charter extension is typically not for more than three months. If you
think that's not enough time, then we need a new charter. The new charter
can be shorter than two years. It can be one year also.

BB: The extension is really for a brief period. If you just have to finish
something and you're almost finished, then you can do that. But If you
still have to go to a CR or to a recommendation, then it probably is better
to have a new charter.

NS: So, in terms of CR, can you remind everybody what the process is?

BB: Well, the horizontal review and all other reviews should actually be
continuous. There should already have been reviews from the horizontal
groups. You need to show, before going to CR, that you have had sufficient
review: that all the horizontal review groups have had their say. They may
have said "no review from us", and that's okay. But they need to say
something.

BB: And you need to show that there have been other people commenting on
the spec as well.

NS: So in terms of Deyan's question about milestones, I think Maybe a
milestone to hit would be, say, July 1st, we actually request horizontal
reviews, because it's something you have to request. The groups aren't
proactive and saying, oh, here's this spec. Let's go review it.

BB: It takes about two months to get a new charter.

*ACTION*: NS: Our current charter ends October 13, 2025. Our Horizontal
review should start July 1. Our recharter writing should begin August 1.

DG: Can we be done this year?

NS: Completely done might be an over statement.

NS: Done would be like, we've got to CR. When we've got that done. It's
out. It's in the world.

NS: We're probably not going to do a lot more, but there'll be feedback.
Some changes to the spec might happen after that.

NS: You are kind of finished after the CR.

NS: It's maybe not the case with core because we keep finding issues with
core. But I think for full, it's probably going to be the case that we're
kind of doneish.

NS: But it takes about six months for a candidate recommendation to stay
out there to get the Stage where we say, okay, please vote on this to be a
recommendation. And then that takes another month or six weeks, and then
move to the proposed recommendation.

BB: How long the CR lasts depends on how quickly you can write tests and
have them implemented.

BB; There is probably not going to be a PR anymore.

BB: So if there was enough reviews during the CR period then you can go
straight to a recommendation.

NS: The web browsers have nothing to do other than make sure they stick it
in the accessibility tree, which I think they're doing anyway.

NS: And it's really, it's like, well, who's going to generate it? Who's
going to consume it? And none of those are web-based. So maybe it's more
like aria uh how they do test.

NS: How does ARIA test?

BB: That's a good question. I don't know. I know that not everything they
do can be automatically tested. So probably some of the tests will involve
people actually writing reports about what they see.

DG: Is the end of 2026 a realistic target?

NS: I would say a pessimistic target is the end of next year. I would hope
we have CR this year, maybe as soon as mid-fall, so maybe October time
frame sometime in October, maybe we get to CR.

NS: And then, you know, we'll see how people do on their implementations.
But I would expect probably springtime we'd be moving to, again, this is a
little optimistic, be moving to having the actual recommendation.

NS: All the screen readers will be using MathCAT so people could claim that
JAWS and NVDA are not independent implementations.

Ns: Murray has another application that could be considered an independent
consumer.