Minutes: MathML Full meeting, 20 Feb, 2025

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Paul Libbrecht
   - Deyan Ginev
   - Bert Bos
   - Patrick Ion
   - Murray Sargent
   - Stella Voutsina

<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-0-regrets>
Regrets

   - Bruce Miller
   - Moritz Schubotz

<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* DG and SV offered to take on some spec or code writing tasks.
<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 test his solutions on a Mac.

*ACTION* DC: I should look at exactly what wording changes the spec should
have.

*ACTION* DC will make a pull request so that people can review his changes.
<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>

(updates/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>

(updates)

*ACTION* If you have any comments for issue 279, please submit them before
the core meeting on Monday, February 24, 2025. If there are no comments,
then we should close this issue.
<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>

(any new ideas on how to move forward?)

*ACTION* SV will look at issue 525.

*ACTION* MuS: I'll change the codepen to have a fraction or something to
make label alignment more difficult in issue 525.

*ACTION:* NS will modify the codepen to provide more complicated examples
in issue 525.

*ACTION* NS: Will put issue 525 on the February 24 core meeting agenda.
<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

*Action* DG and SV offered to take on some spec or code writing tasks.

NS: We are at the point where we've got 10 open issues on writing the spec
and 7 open issues on writing polyfills. Those need to get done before we
can move on to the candidate release (CR).
<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: I has some simple CSS which is useful for alignment. It looks quite
nice now, and we can generate that from Latex automatically.

NS: But we do need to turn it into a polyfill?

DC: Yes.

DC: I just changed the spec text. I'm hoping to get a PR for that this
weekend.

MuS Checked out what DC did. DC's methods did not work out well for safari.

MuS: My code worked in Edge (Chrome). Firefox, and Safari.

*ACTION* DC will test his solutions on a Mac.

DC: You can polyfill differently for different browsers.

*ACTION* DC: I should look at exactly what wording changes the spec should
have.

MuS: Our malignmark and maligngroup work arounds don't handle more
complicated equations with built-up fractions correctly. The symbols aren't
lined up vertically correctly.

*ACTION* DC will make a pull request so that people can review his changes.
<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>

(updates/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>

(updates)

*ACTION* If you have any comments for issue 279, please submit them before
the core meeting on Monday, February 24, 2025. If there are no comments,
then we should close this issue.
<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>

(any new ideas on how to move forward?)

DG: If you're very motivated to get the best possible modern leverage of
CSS, I think it's probably your best course of action to get equation
numbers aligned.

NS: Would CSS grid interfere with the rest of the layout?

DG: Probably.

DG: So you have to be careful to separate it out. On the table itself you
need to make a grid, and then you need to make sure the inner context where
the math is turns into display math.

*ACTION* SV will look at issue 525.

DC: The issue is how to get the equation number flush with the page margin.

DC: Your solutions are different for each type of browser.

NS: We made a labeled row whose first element was the label. So David's
proposal here is that we do that, except that now, instead of having an
mlabeltr, we put some intent on the thing that makes it a label that CSS
could pick out and move it to the right or left.

*ACTION* MuS: I'll change the codepen to have a fraction or something to
make label alignment more difficult in issue 525.

*ACTION:* NS will modify the codepen to provide more complicated examples
in issue 525.

NS: We're kind of jumping the gun here, because we haven't decided whether
this is a good idea or not, and we should do that before we spend a lot of
time trying to make it work.

NS: Let me summarize. Alternatives are to put the label outside of the
MathML. The problem there is that you can't get baseline alignment easily
because you do not know where the baseline is.

NS: The other issue is that for accessibility it's no longer in the flow,
and the screen readers will not read the equation label.

NS: remembered that DG proposed using aria-labeled-by on the row. And so
that would be a way, maybe to link the external label to that for
accessibility. But it still doesn't give the visual presentation alignment.

DC said to put the equation labels in the final column.

DG: It is common to see tables, figures, and equations labeled and
referenced inside a document.

DG: So there are several questions. There's the presentation so that it
looks good in the context of the equation. There's the navigation. And then
there's the accessible readouts, which is the non-presentational way of
vocalizing these numbers.

DG: We are missing a question to ARIA whether they have thought about this
issue because there does not seem to be a standard way to label figures,
tables, and equations. You should be able to navigate every label and be
able to jump to every label.

From Murray Sargent to everyone: Our malignmark and maligngroup work
arounds don't handle more complicated equations with built-up fractions
correctly

NS: This is a good topic for the Core meeting.

*ACTION* NS: Put issue 525 on the February 24 core meeting agenda.

DG: There are line numbers in code blocks.. you have a constant line
height.

NS: If we cannot label equations with CSS, we can label them with polyfills.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-0-6-a-href-https-github-com-w3c-mathml-issues-526-526-core-concepts-re-organize-trig-log-functions-a->6
#526: Core concepts: re-organize trig/log functions?
<https://github.com/w3c/mathml/issues/526>

NS: In the core concept list
<https://w3c.github.io/mathml-docs/intent-core-concepts/> we have a list of
operators, and that was a short way of listing these things as being in
core, giving their fixity, and associated concept names and Unicode symbols.

NS: We had earlier agreed that it's best to put an intent as low as
possible, so rather than having an Mrow with a plus on it and then listing
out all the arguments of the Mrow. It's simply better to put, say name plus
for the concept on the plus sign.

NS you should put a name of sine on "sin" and cosine on "cos".

From Deyan Ginev to everyone: I agree,

sin

looks great to me.

NS: Why do we not include the trig functions like the list at the top of
the core list?

NS: My initial plan was to shrink the list.

NS: A second issue was to make an automatic mapping of the symbol name to
the concept.

NS: DG asks, are these assumptions always true? Do we override this with a
literal if it is not true?

PI: Are you helping AT, or are you getting into semantics?

PI: I believe you are just trying to help AT.

DG: The core list is a big win. We do not want to overextend. None of the
k-12 concepts apply fully to higher mathematics.

DG: What we want to say is that here is this wonderful core list.

DG: We would have a toggle where we should leave the default to be
"legacy", and discuss if common could leverage the list directly.

DG: I think you can do a lot of this with JavaScript so there are 2 uses
for this list. One is to just view it in your browser, and you could
compress it as you render it.

DG: The second user of this list would ingest it inside an editor or data
structure inside a program that could work on intent.

DG: You could facilitate both uses easier if you have a uniform YAML file,
and then you just have flexible presentations of that file.

DC: It would be nice for me if we decided to pull all the trig functions
out into a list at the top.

DC: We could decide whether we wanted to change the yaml, or just do it in
the display.

DC: Most of these would be arity one functions.

DC: What you are losing is the speech template. that is OK if the templates
are all the same.

DC: If you want to use different speech templates, you've got to put them
somewhere.

DG: A practical suggestion for your earlier problem. You treat French
differently than English. If you just treat British and American the way
you treat French, you should be able to split it out cleanly. Just treat
them as 2 different languages.

DG: Would the Yaml file be compressed with a stable algorithm so that the
YAML file could be uncompressed into the original full entry?

DC: We should be saving the speech templates. If you are not guiding the
speech, then you are not doing much at all.

NS: My suggestion would be to add another field saying that this is part of
this shrunken set.

NS: I don't think we've done anything yet, especially about mapping the
symbol name to a concept.