Minutes: MathML Full meeting, 13 Feb, 2025

 Attendees:

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

<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-0-regrets>
Regrets
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-0-action-items>Action
Items
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

*ACTION:* PL is considering preparing a talk on the topic of accessibility
demonstrating intent, MathCAT, and a couple of authoring tools, for the
Breakouts Day.

*ACTION* NS will add an issue on how to process the arguments of unknown
concepts.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-0-2-a-href-https-github-com-w3c-mathml-issues-181-181-mathml-4-extensions-for-alignment-and-possible-deprecation-of-maligngroup-and-malignmark-a->2.
#181: MathML 4 extensions for alignment and possible deprecation of
(maligngroup/) and (malignmark/) <https://github.com/w3c/mathml/issues/181>

(updates?)

*ACTION:* DC will put out a PR saying that maligngroup and malignmark can
be deprecated because there are CSS solutions which can replace them.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-385-385-comments-on-chapter-3-a->3.
#385: comments on chapter 3 <https://github.com/w3c/mathml/issues/385>

(new thoughts on how to handle examples?)

No updates.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-0-4-a-href-https-github-com-w3c-mathml-core-issues-279-279-core-clarify-the-language-around-deprecated-features-of-mathml-a->4
#279 (core) Clarify the language around deprecated features of MathML
<https://github.com/w3c/mathml-core/issues/279>

*ACTION:* NS is waiting for other people to give their comments on how the
37 attrs, discussed in this issue, should be used.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-0-5-a-href-https-github-com-w3c-mathml-issues-525-525-equation-numbers-a->5.
#525: Equation Numbers <https://github.com/w3c/mathml/issues/525>
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-1-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

W3C Breakouts Day 2025 (26 March)

To view proposed sessions: https://github.com/w3c/breakouts-day-2025/issues

If there are sessions of particular interest to you, we encourage you to
express support through GitHub emojis.

To propose a session:
https://github.com/w3c/breakouts-day-2025/issues/new?assignees=&labels=session&projects=&template=session.yml

For information about good practices, proposing a session, and more, see:
https://github.com/w3c/breakouts-day-2025/

NS: The deadline for proposing a new talk is March 12. A stable schedule
will be published on March 21.

*ACTION:* PL is considering preparing a talk on the topic of accessibility
demonstrating intent, MathCAT, and a couple of authoring tools, for the
Breakouts Day.

DG: I just got two notifications on GitHub that two MathML issues, proposed
for interop in 2025, have been declined. Interop will not be working on
MathML in 2025.

From Deyan Ginev to everyone: The interop effort is 0 for 3 if anyone is
keeping score.

NS is reviewing MathCAT to make MathCAT follow intents. He has discovered
some problems. One example would be that we have sums and products which
are listed as functions but do not have arguments. Trig functions also have
this issue. For example (sin + cos)(x), where "sin" has no argument, so
some things have to be considered to be "nofix". You know the fact that
there's an invisible apply, or some other thing would make sense.

DC: Isn't that always the case? If there's no argument, it'll just be the 0
match. Every entry can have a standalone entry with zero arity. Everyone
can have that.

NS: Then the spec does not apply because zero arity is not one of the
listed cases. For your example, you would just say "sin".

DC: You could add a zero-argument template case.

DG: Do you want to add a new template for every entry?

NS: Then we must write, at the top, something saying that all the entries
have a zero arity case which must meet the spec in some way. MathCAT does
not process this case.

NS has another issue. Consider dollar one, choose dollar two. But what
happens if the arguments to the binomial aren't simple? So I need to be
able to put some begin and end words to bracket that. So if it was N plus k
choose n minus k or something like that.

NS: How can you determine whether grouping is needed? So if it were a
linear thing, then, well, people would have written parentheses and that's
how you would have known that it's grouped. But when it's not linear, it's
vertically displaced.

NS: So we indicate, oh, here's a sample, one, choose $1 2, but we don't
have samples of what to do when it needs bracketing words. So for example,
I'm still trying to figure out what's the word that I say at the beginning
of this and what's the word that I say at the end? Do I say binomial?

NS: We could use the vocabulary for permutations. Where, okay, how do I
bracket the permutations if there's an N plus one and a choose K
permutations of k minus one or something. What words should I use? The
words are not in the spec.

NS: I thought of begin group and end group.

DC: Can not you just announce the beginning end of each term and have an
infix plus in the middle, wouldn't you?

DG: Two thoughts. First, I kind of like the idea that this is a fruitful
area of experimentation and ATs have freedom to do what they like.

DG: The second thought is that we should provide a fallback behavior for
how to render the arguments of unknown concepts. I would name them after a
generic word for argument rather than after the concept so that you get the
exact same wrappers for every concept that's unknown.

NS: Maybe I should say arg1, arg two, arg three. So I'm unsure of what to
do.

DC: The argument order's not very informative. For example if you are told
that this is a second argument of an unknown function, you do not know what
you have.

From Deyan Ginev to everyone: We can always go even more generic: "slot-1"
... "end-slot-1"

DG: I usually go for extreme examples to illustrate the principle or to
find it. In this case I'm thinking of a fancy-sum. Fancy-sum is an unknown
concept. Fancy-sum, and then you give it 9 arguments. And then the question
is, would the listener get lost? If you just say start argument, end
arguments, and probably they would. If you have 9 of them, you may even
want to say, start argument 8, end argument 8. I would name them after a
generic word for argument rather than after the concept, so that you get
the exact same wrappers for every concept that's unknown.

DG: Don't we have a healthy example where this works really nicely with
tables, where you can actually traverse the table? And you hear, this is
row 52, column 43, row 52, column 44, row 52…

DG: So a consistent user experience where you hear the same words with a
number at a very predictable place in the speech may in fact be quite
usable to a screen reader user.

NS: The issue is it's unclear what argument is what.

*ACTION* NS will add an issue on how to process the arguments of unknown
concepts.

BM: Some special functions have arguments, and some extra arguments, which
are called parameters.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-1-2-a-href-https-github-com-w3c-mathml-issues-181-181-mathml-4-extensions-for-alignment-and-possible-deprecation-of-maligngroup-and-malignmark-a->2.
#181: MathML 4 extensions for alignment and possible deprecation of
(maligngroup/) and (malignmark/) <https://github.com/w3c/mathml/issues/181>

(updates?)

DC: There is a proposal in the issue that we basically make both of those
valid, but with no defined behavior, and there was a polyfill to make the
MathML behavior work. we can only sort of do that because DG supplied some
funky CSS that actually worked.

*ACTION:* DC will put out a PR saying that maligngroup and malignmark can
be deprecated because there are CSS solutions which can replace them.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-1-3-a-href-https-github-com-w3c-mathml-issues-385-385-comments-on-chapter-3-a->3.
#385: comments on chapter 3 <https://github.com/w3c/mathml/issues/385>

(new thoughts on how to handle examples?)

No updates.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-1-4-a-href-https-github-com-w3c-mathml-core-issues-279-279-core-clarify-the-language-around-deprecated-features-of-mathml-a->4
#279 (core) Clarify the language around deprecated features of MathML
<https://github.com/w3c/mathml-core/issues/279>

*ACTION:* NS is waiting for other people to give their comments on ow the
37 parameters, discussed in this issue, should be used.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-1-5-a-href-https-github-com-w3c-mathml-issues-525-525-equation-numbers-a->5.
#525: Equation Numbers <https://github.com/w3c/mathml/issues/525>

NS: How do you put labels on equations? We used to have Mlabeltr, but we
decided to deprecate that.

NS: You need to be able to align the equation labels on the rows, and
auditorily announce the labels on the rows.

DC Proposed adding an intent property, called :equationlabel, on the first
element on the row, where it can be spoken.

DG to LM: If you have a multi equation group, usually you have like four
equations. Sometimes you put the number on the second row or the third row,
not in the start, but in the middle. And there are cases where you will
have like a group of equations, and they will have two numbers. So there
will be two notable ones right on top of each other. Would it make sense to
clear up which equation is which by saying start labeled equation and then
end labeled equation?

LM: Yes.

NS: You have this now. The way it's read now is, you do have the bracketing
because you're going to hear "Say, equation one with label 5 or label A or
something like that".

NS: Sometimes a label is for a complete set of equations.

BM: There's two separate coupled issues here. One is how you say things,
and the second issue is how you actually disambiguate and mark up With
intent. You know, when you have a group of aligned equations some equations
are one row, some are multiple the Label could be to the left or to the
right. It might be in any of those rows.

BM: If we have a property that says that this particular cell is a label,
it could be anywhere within between the start equation and equation, so the
system is going to have to search for it.

BM: In a paper, the labels will be all either on the left or right. They
will not put labels on the left and right within one paper.

DC: The first column in all cases would be a label, and you, if it was
empty, you put an intent, no equation label or something, you wouldn't have
to search. So you just know up front that the first column has labels, and
for the most common thing that's got a multi-line is displayed with a
single number.

DC: You shouldn't lock it up this way. It should be an Mtable within a
numbered equation. So the numbering is then outside, and the display is
just a term in a single numbered equation.

DC: The whole display has a single number on the Math Axis.

DC: So they're 2 completely separate things. So there you've got one number
for the entire display, which is usually centered. But you also don't
sometimes do it by putting no number, no number, no number, putting a
number on roughly the middle row, and then no number, no number, no number.
But that's not the right way to mark it up. It should be marked up as a
display.

DC: You have an mtable with a lot of stuff, but the label is not part of
the mtable.

DG: Due to stylistic changes, a preprint can have the equation labels on
one side, and in the journal, the equation numbers can be on the other side.

DG: You should be able to navigate from the text in the paper to the
equation label via a link process. Once you arrive at the equation label,
you should see the equation.

DC: The linking is separate from the numbering.

NS: If the label is part of the math, it might not be findable by the web
page search process.

NS: Put an attribute value on the mtr. It is not just text. You could put
anything with a tag like primes. The attribute value will never work
without a polyfill.

DG: We could integrate SVG and MathML into the same diagram. It's
difficult. We should defer it until we can do it well. With open, we can
use an intent reference. You can use silent or underscore to silence the
default bracketed number. You can add either a literal or something else to
vocalize exactly what you want to hear. And you can craft something as an
experiment to see what works.

NS: I see a 5 by 4 matrix, but one column might be labels. It should be a 4
by 4 table. If one column were labels, you cannot say how big the table
really is. If you have an explicit label, then at least the counting can be
done properly.

From Deyan Ginev to everyone: "works in a polyfill" is fitting for a
deprecated feature :)

MuS: What happened to mlabeledtr, the element Oh, because that works in
MathJax.

NS: It got deprecated because it would never be supported in core.

BM: What is the danger in introducing a property like :label to put on the
equation.

BM: We're comparing that situation to the situation where people will have
a whole variety of weird markup to hide the label. It seems like something
like a property label is innocuous enough that If you're reading a system
of equations you can ignore anything that's labeled if you're processing it
as content.

DG: I'll just answer Bruce's point about the danger. So we're very used to
this mental model of things suggested by NIO being implemented since he is
the AT implementer. But the more core properties you have, the less
implementers you have because the spec is harder and harder to implement.
Properties are harder than concepts. This is not going to solve the
problem, and it still requires an implementation if it's in core. And it's
not an obvious one. It's actually quite subtle.

DG: I don't want to force everybody to restructure their mtables to have
the label in the first TD, which is the current proposal in the thread.

DG: So there's a lot of friction that you introduce property by property
where the end result is so much strange work that You don't want to do it,
or you don't want to start.