Minutes: MathML Full meeting 4 April, 2024

 Attendees:

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

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

   - Paul Libbrecht

*LM* In what follows, "less than a greater than" was not visible in the
CryptPad output. For this reason, I changed "less than a greater than" to
(a).
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0-action-items>Action
Items

*ACTION* MuS will add CGS (Centimeter, gram, second) units to the units
list. Please indicate which CGS units are not already on the list.

*ACTION* DC will reach out to Chinese TeX groups and ask them about units
used in Asian languages. Do they see these symbols in publications?

From Deyan Ginev to Everyone: Chinese units:
https://en.wikipedia.org/wiki/Chinese_units_of_measurement

*ACTION* DC will check Fred's changes in issue 103: percentage of
minsize/maxsize <https://github.com/w3c/mathml-core/issues/103>.

*ACTION* MuS can try the test cases out in word for issue 205: Vertical
Alignment of delimiters <https://github.com/w3c/mathml-core/issues/205>.
MuS should play around with the sizes in mrow and see what the automatic
scaling does for parentheses. What does word do?

*ACTION* DC should reply that neither TeX nor Word support asymmetric
stretching. DC will make a comment about this in this PR.

*ACTION* MoS will add an issue of how does TeX use big or bigger and
convert it to MathML. He should do this on the MathML list.

*ACTION* NS will open an issue on larger parens and Matching requested
fixed sizes. He will open this on the MathML core list.

*ACTION* DG should add this comment to issue 142 Should all MathML elements
really be potential hyperlinks / match :visited?
<https://github.com/w3c/mathml-core/issues/142>: DG: Is there's any path to
get both href and (a) but specify a fallback mechanism for in Mrow where an
mrow with an href degrades into an (a) as a recovery mechanism prescribed
by MathML core? This would allow existing documents to be translated.

*ACTION* If anyone has anything to add to the issues we discussed in this
meeting, please put the comments into the appropriate issues.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

NS: There are some action items from last week's meeting. NS reviewed his
action items.

NS has updated the units to include a little more on degrees. From
Wikipedia he has added: radians and steradians. He has moved degrees from
accepted units to derived units. He has added directions. NS added a
mention that units can involve not just being alone, but can have powers,
can have negative powers, and can be involved in division.

NS added Fermi, which is a unit of length that is equivalent to one
femtometer, which is 10^{-15} meters.

NS said that PL added a link to a document discussing currencies.

NS: So, the action item was to write down stuff from the standard. I don't
think the Iso standard, which has currency codes, was particularly useful
because nobody uses the actual currency codes.

DC: People do recognize currency codes like GBP for British pound sterling,
and USD for U.S. dollar.

NS: In math, the dollar sign would be used more often than the code USD.

NS entered some Unicode symbols for some currencies.

NS: We will discuss currencies later.

NS looked at the English units but decided that some of the more obscure
units need not be listed.

NS: There are units which have alternative notations. NS tried to boldface
the main definition of the units.

MuS: I was wondering a little bit about the CGS units. NS covered MKS
units. A lot of physics does use Cgs, so like you have Esu for
electrostatic unit. I didn't see that in the list. I didn't go through all
the units to see what was missing. See
https://en.wikipedia.org/wiki/Centimetre%E2%80%93gram%E2%80%93second_system_of_units

*ACTION* MuS will add CGS (Centimeter, gram, second) units to the units
list. Please indicate which CGS units are not already on the list.

DG: CVE stands for Common Vulnerabilities and Exposures. It’s a list of
publicly disclosed computer security flaws. DG put a link to the
MathML-related CVEs on record, currently 8: NIST national vulnerabilities
database
<https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=MathML&search_type=all&isCpeNameSearch=false>
in issue 227: Sanitizer API <https://github.com/w3c/mathml-core/issues/227>.

DG: added screen shots of Appendix B: table of 24 unit conversions, and he
added Appendix C: physical constants, mentioned in his physics list, to his
physics list (
https://gist.github.com/dginev/825078ae316c32c312436f42061b3d05).

DG is getting the big list of units requested in the March 28 intent
meeting. The list may be completed next week.

DG has found Unicode characters for units in several languages such as
Chinese, ancient Greek, Egyptian, and Indian units. He thinks there's
Japanese and Singaporean units. He found there's a whole lot of
non-mainstream units. Some were replaced by the metric system. Unicode
characters exist for some of these units.

NS: Probably not going into core.

NS: We do not have any Asian background people in the group.

NS: Do we have any friends who are knowledgeable about these things in
Asian countries that maybe we can query them to ask if we need to add these
units to our list?

*ACTION* DC will reach out to Chinese TeX groups and ask them about units
used in Asian languages. Do they see these symbols in publications?

From Deyan Ginev to Everyone: Chinese units:
https://en.wikipedia.org/wiki/Chinese_units_of_measurement
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0-2-issue-discussions-further-comments->2.
Issue discussions (further comments?)
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0--a-href-https-github-com-w3c-mathml-core-issues-103-percentage-of-minsize-maxsize-103-a->percentage
of minsize/maxsize (103) <https://github.com/w3c/mathml-core/issues/103>

DG: MathML 3 remains the correct formulation for MathML core.

NS: This is about stretchy characters and whether percentages were based on
whether it was a percentage of the normal size or the stretch size, I
think, is what it turned into. It is considering symmetry.

NS: I believe it is more or less resolved.

DG: Fred has changed some things.

*ACTION* DC will check Fred's changes in issue 103: percentage of
minsize/maxsize <https://github.com/w3c/mathml-core/issues/103>.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0--a-href-https-github-com-w3c-mathml-core-issues-205-vertical-alignment-of-mo-delimiters-205-a->Vertical
Alignment of delimiters (205)
<https://github.com/w3c/mathml-core/issues/205>

DC: It is broken in Chrome.

BM: The spec is ok but there are bugs in the implementations.

NS: Ronkok is putting in an mrow. I'm not sure why he didn't use an "em"
space, but he's changing the size of the mrow, and then saying, Well, what
happens to this parenthesis when you do that change?

*ACTION* MuS can try the test cases out in word for issue 205: Vertical
Alignment of delimiters <https://github.com/w3c/mathml-core/issues/205>.
MuS should play around with the sizes in mrow and see what the automatic
scaling does for parentheses. What does word do?

NS: If you change the size of something in the parentheses, do the
parentheses also change?

MuS: No, it is automatic.

MuS: I have a feeling that word does not respond to this stuff, but I do
not know.

DC: TeX cannot manage symmetric = false.

DC: You cannot stretch asymmetrically.

NS: Stretching is symmetric for TeX and word.

*ACTION* DC should reply that neither TeX nor Word support asymmetric
stretching. DC will make a comment about this in this PR.

BM: Something came up in the discussion about The potential difference
between percent and em for minsize and Maxsize, and there was a subtle
question of interpretation that I would like to make sure that DC and I are
understanding things the way everyone else is understanding them.

*LM:* In what follows, the transcript seem to use "point" and "pixel"
interchangeably.

BM: If you would say, minsize equals Maxsize equals 20 points, is this to
be interpreted as if one requested a 20-point font, which is kind of the
way you would think of it coming from the TeX world, or are you saying you
want the parentheses to be 20 pixels?

NS believes that you are not changing the font. You are asking for the
closest fit to 20 pixels for your parentheses.

NS: Does not know if the size fitting algorithm would pick the parentheses
closest to it from below, or closest to it from above or just pick the size
is closest to the requested size regardless of whether it is below or above
the requested size.

MoS: That is exactly one of the issues we are facing when we wrote this new
converter. He would like to have a discussion of how to convert TeX to
MathML for issues involving sizes.

NS: Suggested having this discussion in a GitHub issue.

NS sees an issue with the spec that needs to be resolved which is that
question of if you ask for a 20 pixel high paren, and you don't have a 20
pixel high paren in your font, does it pick the one that's is closest to it
from below, or closest to it from above, or just the one that is the
absolute closest.

DC: If you asked for a fifty-pixel bracket, most fonts would switch to a
constructed bracket.

MuS: In the math typography spec, there's another parameter, called the
shortfall, which is emulating something that TeX does. So, you may find
that the paren will be a little bit smaller than the desired size. It isn't
always necessarily bigger than the desired size.

DC: TeX has delivered to shortfall and delivered to the scale factor. But
that's not for this. That's not when you specify the fixed size. That's how
you modify the size of the content.

*ACTION* MoS will add an issue of how does TeX use big or bigger and
convert it to MathML. His issue will include what do we do if both minsize
and maxsize are used at the same time with the same value. He should do
this on the MathML list.

*ACTION* NS will open an issue on larger parens and Matching requested fix
sizes. He will open this on the MathML core list.

BM: There may not be a fixed answer to MoS's question. We continually tweak
what we generate.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0--a-href-https-github-com-w3c-mathml-core-issues-142-should-all-mathml-elements-really-be-potential-hyperlinks-match-visited-142-a->Should
all MathML elements really be potential hyperlinks / match :visited? (142)
<https://github.com/w3c/mathml-core/issues/142>

NS: Where can href go. Should we allow it on mrow, or should we create a
(a) element.

NS: href on mrow works on Firefox and Safari.

NS: If you use href on an element, then you cannot include it in the shadow
dom.

NS: The alternative is to include an (a) element which does not work
anywhere now.

NS: (a) is now not thrown out in chrome, but it does not do anything.

NS: But then it also breaks all these MathML implementations that aren't
expecting an (a) element, because they say, Well, this is illegal MathML.
However, it does allow mrow to go into the shadow dom.

DC believes we should use (a).

BM Why does it matter if you use (a) that is called "a".

NS: BK believes that the closer MathML gets to html, the better off
everyone will be.

*ACTION* DG should add this comment to issue 142 Should all MathML elements
really be potential hyperlinks / match :visited?
<https://github.com/w3c/mathml-core/issues/142>:

DG: Is there's any path to get both href and (a) but specify a fallback
mechanism for in Mrow where an mrow with an href degrades into an (a) as a
recovery mechanism prescribed by MathML core? This would allow existing
documents to be translated.

DC says to add (a) to MathML 4. MathML 4 will have both because href is not
leaving.

BM Formerly xlink was the proposed way for linking to be done.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0--a-href-https-github-com-w3c-mathml-core-issues-227-mathml-support-in-the-html-sanitizer-api-227-a->MathML
support in the HTML Sanitizer API (227)
<https://github.com/w3c/mathml-core/issues/227>

DG: They have their own sets of considerations about what's unsafe and what
they're guarding against, that don't usually make sense entirely if you're
not using exactly the browser context they have in mind. So, it's an
extremely specific kind of sanitization for one context. And I am
particularly interested in the data attributes because the media annotation
elements in MathML are remarkably similar to data attributes and in certain
sanitation contexts, you just don't even worry about them because they're
mostly safe. They're so strict that they even sanitize away data
attributes. However, they have a flag where you can configure whether you
do or do not want to sanitize them.

DG: My comment here was "that's reasonable". We have some elements in
MathML that are kind of borderline, not really unsafe. But if you wanted
to, you could remove them. My suggestion was, if you can give us a flag,
then you can decide whether to keep them or remove them with that flag for
whatever use case you have. Frederick seems to be in favor of that ,which
was nice.

DG: PL's comment was that most things are safe in MathML. We don't have
that much behavior specified. Action is the one exception.

NS: Maction is not in core.

*ACTION* If anyone has anything to add to the issues we discussed in this
meeting, please put the comments into the appropriate issues.