Minutes: MathML Full meeting 23 Jan, 2025

 Attendees:

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

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

   - Moritz Schubotz

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

PL: The group supporting the sanitizer wants to eliminate mphantom because
mphantom hides things. The MathML WG intent group wants to keep mphantom.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#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?)

No updates.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-482-482-intent-for-large-operators-a->3.
#482: Intent for large operators <https://github.com/w3c/mathml/issues/482>

(new thoughts on the property name?)

NS: We're Still looking for a new name for the large operator property
other than "largeop". By next week, we will be ready to move on.

No updates.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-4-a-href-https-github-com-w3c-mathml-issues-433-433-comment-include-or-not-a-sample-set-of-default-conversion-from-plain-mathml-to-mathml-with-intent-a->4.
#433 (comment) include (or not) a sample-set of default conversion from
plain-MathML to MathML-with-intent
<https://github.com/w3c/mathml/issues/433>

(discuss need for "Common" for "intent-default")

NS: I was going to add literal and common to the core intent list, but it
doesn't fit the format Because there's some commentary and there's bullet
points and things like that. It really doesn't fit in here. So I actually
created a separate document "
https://w3c.github.io/mathml-docs/literal-common-properties#literal-property
".

*ACTION* NS: I should expand the default section to indicate alternative
modes of speech and language more clearly.

*ACTION* NS: Put h bar on the list.

*ACTION* NS: The line "trig function names might be expanded" should be
removed.

*ACTION* NS: mroot – “root with” index “and contents” contents should be
spoken as root arg 1 of arg 2.

*ACTION* NS: for msubsup msup – arg1 “superscript” arg2. it should say,
"and superscript".
5. #385: comments on chapter 3 <https://github.com/w3c/mathml/issues/385>
(new thoughts on how to handle examples?)

No updates.
6:#120: Remove/deprecate/simplify the ms element
<https://github.com/w3c/mathml/issues/120> (both core and full -- where are
we on this?)

*ACTION* DG is contacting Fred Wang for Fred's opinion on this.

No updates.

<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

PL: The group supporting the sanitizer API wants to eliminate mphantom
because mphantom hides things. The MathML WG intent group wants to keep
mphantom.

PL: This group is probably part of the members of the Web Apps group.

NS: Do they somehow block CSS?

PL: Yes.

PL: There's a limit to this, because, you know, interpreting CSS basically
requires a lot of things, and I do believe browsers are able to do that.
They are able to do, as far as you know, detecting that in the current
layout. The font is too small, and I should remove this thing where the
font is too small or the color is made invisible, or whatever trick.

NS: Well, the other standard trick is to move something off screen.

MuS: Well, we have to fight back on M Phantom. That's ridiculous to
suppress that.

PL: It is better to get an imperfect sanitizer accepted than not to have a
sanitizer.

NS: I do not think that mphantom is uncommon.

MuS: Doesn't mphantom work right now? I thought it did. I can check.

NS: I don't know when the sanitizer runs. It can't run on normal pages,
otherwise, all the web would be broken, because hidden is used all over the
place.

PL: No, it would run on a copy/paste, or if you respond to a mail or where
you change context into a trusted context.

muS: Oh, so that's not so serious.

PL: It would be interesting to get the statistics about M Phantom. I still
think there is an advantage into getting this including a fair amount of
elements Because there are things which currently disappear because MathML
is not trusted.

NS: Bruce, does LaTeXML generate mphantom?

BM: Yes, it does, I believe.

NS to DG does the Archive use mphantom?

DG is looking.

From Deyan Ginev to everyone: mphantom report from 2018:
https://gist.github.com/dginev/e50a632d31be05bb87d64cc1800f6fd4#file-pmml_cutoffs-csv-L208

DG: This report says that mphantom occurs in the Archive about 50,000
tines. This is about one percent of the math formulas in the Archive.

PL: The sanitizer does not do replacements. It removes things.

NS: Removing mphantom will break MathML.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#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?)

NS: David, last week, you said that you and Murray had a talk, and you guys
agreed that we could get rid of them, is that correct?

DC: So nothing's happened since last week. I was trying to understand why
we need float.

MuS: Well, there's a bit of an update. I found that Firefox does it
correctly without the float. And I think it's a bug.

MUS: Safari also does things correctly without the float.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-3-a-href-https-github-com-w3c-mathml-issues-482-482-intent-for-large-operators-a->3.
#482: Intent for large operators <https://github.com/w3c/mathml/issues/482>

(new thoughts on the property name?)

NS: We're Still looking for a new name for the large operator property
other than " largeop". By next week, we will be ready to move on.

No updates.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-4-a-href-https-github-com-w3c-mathml-issues-433-433-comment-include-or-not-a-sample-set-of-default-conversion-from-plain-mathml-to-mathml-with-intent-a->4.
#433 (comment) include (or not) a sample-set of default conversion from
plain-MathML to MathML-with-intent
<https://github.com/w3c/mathml/issues/433>

(discuss need for "Common" for "intent-default")

NS: I was going to add literal and common to the core intent list, but it
doesn't fit the format Because there's some commentary and there's bullet
points and things like that. It really doesn't fit in here. So I actually
created a separate document "
https://w3c.github.io/mathml-docs/literal-common-properties#literal-property
".

NS wrote: The :literal and :common core properties establish a set of
defaults for speaking every MathML element that MathML intent generators
can assume, and that AT should implement. That does not mean that the exact
words are specified, only that AT chooses words that convey the default
meaning. For example: msup is spoken as “super” or “superscript” or some
similar words if that element or some ancestor includes the :literal
property. The exact words may depend upon both the audience and the
children of node. In particular, for someone who is blind, it may be
important to indicate the start and end of fractions, roots, etc.

NS: Let's start walking through the literal properties and see what people
think.

An item that got a comment was: glyph speaks the alt text

NS: Did we deprecate mglyphs?

DC: Even if it is deprecated, you must handle it.

Ns: Should we expand trig function names? So CSC Might be spoken as
cosecant instead of pronounced as CSC.

MuS: If you cursor into a trig name, you want to say the letters there and
not pronounce the full name.

DC: Let's all just say the letters.

NS: We could say that "mi" should be spelled out. Contents should always be
spelled out.

NS: It would be a little weird for things like log.

NS: There seems to be a difference between pronouncing log as log and
pronouncing CSE as cosecant.

NS: For SIN, do you pronounce it sin, or do you pronounce it sign?

NS: We could try to come up with a list of exceptions.

NS: I put the trig names down as exceptions. I was a little concerned about
having a list of exceptions.

MuS: In his UnicodeMathML
<https://murrayiii.github.io/UnicodeMathML/playground/> applet, he says
ampersand and for malignmark and maligngroup when navigating character by
character, but doesn't say anything for them when speaking a whole
expression/equation.

DG: This document is in English and is terse. You cannot tell where a
fraction begins or ends.

DG: You need to say that this is an example of one way to read things. It
is not the required way.

NS: In my introduction, I say: The exact words may depend upon both the
audience and the children of node. In particular, for someone who is blind,
it may be important to indicate the start and end of fractions, roots, etc.

NS: What I should do is, in the defaults, just give a more explicit
example, or have some explicit examples of alternative speech depending on
the audience.

*ACTION* NS: I should expand the default section to indicate alternative
modes of speech and language more clearly.

DG: I have a one-word proposal that will make me happy to the point of
accepting anything inside the documents. You should change the heading
"defaults" to "example defaults".

NS: Okay. So this is a good question, though, in terms of what should be in
literal.

NS: What should be said for "mi"?

NS to DG: What do people expect out of the archive for speech?

DG: So the less you assume, the more it's in the spirit of literal. The
spirit of literal is the least amount of assumptions that is still usable
and accessible.

DG: I'm actually worried also about Unicode because most of the "mi's" in
Archive are single letter variables, and Unicode has made some interesting
choices, and we map things into Unicode. The classic example is that you
use the reduced Planck's constant h bar, and you could be looking at an 'h'
with a bar through it.

NS: h bar could be an h with a bar over, not through, it.

DG: There may be many single letter examples in Unicode. "h bar" (U+210F)
is a problem.

DG: What happens when something is not on this list?

NS: The list should be expanded.

From Deyan Ginev to everyone: "h bar" is a great :literal reading

MuS: Unicode names are not ideal and may even be incorrect. Once they are
added, they cannot be changed/corrected.

"h bar" is not on the list.

*ACTION* NS: Put h bar on the list.

MuS: h without the bar can mean many things.

NS What do you do with multiple symbols?

DC Just read it. csc should be read as c s c.

LM: For "mi" do you spell it or pronounce it?

NS: Most of the time "mi" is a single character and we have suggestions in
the table of what to do with it.

*ACTION* NS: The line "trig function names might be expanded" should be
removed.

DG: I have another comment, which is, I guess, more aspirational given that
it's difficult to work with 160,000 characters. The spirit of the literal
property would be to pronounce a typographic description of the character.

NS: Consider how mroot – “root with” index “and contents” contents should
be spoken. People can be confused about what each argument is.

*ACTION* NS: mroot – “root with” index “and contents” contents should be
spoken as root arg 1 of arg 2.

NS: Consider msubsup – arg1 “subscript” arg2“superscript” arg3. As with
msup, exceptions are made when the superscript is a pseudo-script character.

DG: I think you're not conveying enough information, and I cannot infer the
structure. So if you take an example: N Subscript y Superscript 2.

How do I know the structure is an M sub soup, and not y squared in the
subscript.

DC: You've always got the option of begin and end.

DC: You could choose the verbose reading option if the terse option were
not clear.

DG: Perhaps we should choose the verbose reding option for this entire
document.

*ACTION* NS: for msubsup msup – arg1 “superscript” arg2. it should say, and
superscript.

DG: Does Braille automatically add the structure, or not, to expressions?

NS: Yes. The Braille codes all do this differently.

NS: The Nemeth code will state at each superscript exactly what level it's
at each time, and so it may repeat that level, and whatever the other ones
have, if needed, end tags to the to the script. So they'll say start script
and end script.

We will continue this next week.

NS: This is the end of the issues except for the work which needs to be
done on the issues. We are getting close to pushing the spec as a CR.

NS: We have not gotten core to a CR.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-5-a-href-https-github-com-w3c-mathml-issues-385-385-comments-on-chapter-3-a->5.
#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-1#cp-md-0-6-a-href-https-github-com-w3c-mathml-issues-120-120-remove-deprecate-simplify-the-ms-element-a->6:
#120: Remove/deprecate/simplify the ms element
<https://github.com/w3c/mathml/issues/120>

(both core and full -- where are we on this?)

*ACTION* DG is contacting Fred Wang for Fred's opinion on this.

No updates.