Minutes: MathML Full meeting 30 June, 2022

 Attendees:

   - Louis Maher
   - Neil Soiffer
   - David Carlisle
   - Patrick Ion
   - Deyan Ginev
   - Bruce Miller
   - Murray Sargent
   - Moritz Schubotz
   - Bert Bos
   - Cary Supalo
   - David Farmer
   - Paul Libbrecht

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

   - Steve Noble
   - Stephen Watt
   - Sam Dooley

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

MUS: malign: sent an email summarized as:

Microsoft Office apps have the LaTeX concept of an equation array for
displaying aligned equations such as (without alignment marks in plain text)

10𝑥 + 3𝑦 = 2
3𝑥 + 13𝑦 = 4

in which 𝑥's are aligned vertically as are the 𝑦's. The UnicodeMath for
this is █(10&𝑥+&3&𝑦=2@3&𝑥+&13&𝑦=4) which is similar to the LaTeX. The
MathML for this is (without prefixes) is

<math display="block">
<mtable>
<mtd>
<maligngroup/>
<mn>10</mn>
<malignmark/>
<mi>x</mi>
<mo>+</mo>
<maligngroup/>
<mn>3</mn>
<malignmark/>
<mi>y</mi>
<mo>=</mo>
<mn>2</mn></mtd>
<mtd>
<maligngroup/>
<mn>3</mn>
<malignmark/>
<mi>x</mi>
<mo>+</mo>
<maligngroup/>
<mn>13</mn>
<malignmark/>
<mi>y</mi>
<mo>=</mo>
<mn>4</mn></mtd></mtable></math>

So the only way that <malignmark> and <maligngroup> are used is to
alternate between “align” and “spacer”. The MathML 3.0 spec has additional
functionality, but the Office apps don’t use it. OfficeMath also has the
“math paragraph”, which is more flexible in that it handles manual and
automatic equation line breaking.

In a series of equations the malignmark and maligngroup try to align the
equations' parts vertically.

NS: DC, would you do the alignment with a table?

NS: You could align with a polyfill.

NS: We cannot deprecate malign. It is being used.

*ACTION:* NS: will simplify the spec so that maligngroup and malignmark
will match what is used in OfficeMath.

BB: has suggested that the Media Types document be published as a note
instead as a recommendation. This recommendation was accepted.

NS: For spec 4, we must register the new Media Types document with IANA so
that links can be updated to point to the new spec.

*RESOLVED:* make media types draft a Note

*ACTION* DC: will update the spec to show that the media type documentwill
be a Note.

a) reminder about videos

*ACTION* NS: People need to say if they intend to make a technology
demonstration demo, for TPAC, at the July 7 intent meeting.

b) presentation chapter update (Neil)

NS: worked with the deprecations. For menclose, NS is considering
deprecating the long division and square root radical.

NS originally suggested that the menclose default not be long division, but
a box.

DC: suggested that the menclose default would be nothing.

*RESOLVED:* the menclose default would be nothing.

c) content chapter update (Sam?)

d) accessibility appendix (Steve?)

e) other updates?

NS wants an FPWD by TPAC. It does not have to be complete. It just has to
be a coherent document.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-03#cp-md-0-2-what-quot-reserved-quot-attributes-should-be-added-to-core-full-schema->2.
What "reserved" attributes should be added to core/full/schema?

NS: core does not have all the attributes we need, like intent, arg, and
alt text. These need to go into the accessibility tree.

BK: has proposed to say that these are attributes we are thinking about but
we are not defining any semantics for them right now.

DC: wants to add these attributes along with some aria attributes which he
has added to appendix A.

DC: can we say aria-label is in core but undefined?

Things beginning with "data-" are allowed in core. they are there but
undefined.

Aria-label and aria-description would be left undefined. Other people would
ask why not add other aria attributes.

DC: Core should do what the aria spec specifies.

NS: aria-label in the aria spec breaks braille. we would like to get the
aria group to work on math. The aria group does not want to work with math.

DC: We are still discussing whether to use intent or aria.

Deyan Ginev to Everyone: intent intent-arg intent-label intent-labelledby
intent-description intent-describedby ...

NS: intent allows us to use arbitrary strings, except for quotes.

NS: aria-label gives us no advantage over intent.

NS: You can spell out things so that they are pronounced the way you wish.

DC: our intent grammar is open ended.

NS: At this time, we should not discuss what goes into intent.

NS: described his thoughts about how to pronounce chemical objects.

DG: Do you want to specify the pronunciation or the actual content?

NS: Chemistry is a high school subject and should be pronounced correctly.

BM: Would specifying the pronunciation cause a problem with
internationalization?

Ns: We say h two o and u238. The numbers mean different things.

DF: You must disambiguate. it is the point of intent to say what something
is.

NS: We have probably from ten to twenty things to put in core to be able to
work with chemistry. Some of these terms are elements, molecules, and
isotopes.

NS: We do not need to name every element.

CS: You do not have to name every element or molecule.

CS: wants to bring this up with the chemistry group.

DC: Should we remove aria attributes from appendix A?

NS: Yes.

NS: If you put aria into the schema, it is bad for math.

DC: If you put aria into the schema, but we are not defining what it does,
then this is not aligned with the aria spec.

NS: If you put aria in the MathML spec, you will have to make changes in
the aria spec. The aria group does not want to do this. The aria group says
why break things that are working.

DG: said that his demos worked in chrome. Generally if aria sees math, aria
avoids it. DG got around this in his example.

DG: We must decide to use, or not use, aria. If we are not using aria, we
should remove it from the MathML spec.

NS: Core must have some accessibility text. In the MathML 4 appendix we can
say what we would like to do with aria. We will also say that intent
controls speech without damaging braille.

NS: We are making an FPWD and the aria group will review it. This review
may force every one to decide what to do with aria.

NS: It is not good to deprecate aria because it is not currently working
with math.

NS: We should put chemistry in core.

NS: Should we put attributes in core for other subjects such as physics and
biology?

NS: If something is not in core, you can pronounce it only by spelling it
out.

DG: Just let the attribute list of things be open and add attributes when
AT needs them.

DC: wrote the issue reserving intent and arg as global attributes
<https://github.com/w3c/mathml-core/pull/157>.