Minutes: MathML Full meeting 15 Dec, 2022

Thanksgiving is a few weeks in the rearview mirror, but I want to use this
last meeting minutes of the year to give thanks to Louis for a year's worth
of minute taking. This was another fast paced meeting with lots of
technical discussion and I'm sure I speak for everyone in the group when I
say "thank you for your minutes!". All of us really appreciate your efforts.
Attendees:

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

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

   - David Farmer
   - Cary Supalo

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

DG: The MathML archive is ready for release around January 8, 2023. MathML
should work on chrome and edge.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.0-rc3#cp-md-0-2-a-href-https-github-com-w3c-mathml-core-issues-181-deprecating-mstyle-in-core-a-in-full->2.
Deprecating mstyle in core? <https://github.com/w3c/mathml-core/issues/181>
In full?

We had a discussion that, in core, mstyle was equivalent to mrow. Outside
of core, mstyle would accept many more arguments than it would accept in
core. One of these arguments not accepted in core but is accepted outside
of core is linethickness.

DG: wanted to know if there is a renderer of mathematics that is not a
browser, meaning that it's lacking a CSS engine.

DC: Yes, maple, Mathematica, and office.

MUS: said that DG suggested that that mstyle could be used to define the
global properties of mathematics.

MUS: If you want good rendering and user interfaces, you need
document-level properties. You can do this with CSS but not all math
readers use CSS. CSS does not know much about math. This is not the CSS
group's function.

NS: It will be difficult for us to get a global parameter into browsers.

DG: If we do not have a purpose for mstyle, should we deprecate it? Next
year we will have MathML in browsers. We can use CSS to style this.

NS: Does office use CSS?

MUS: Office supports CSS since the beginning of the century. It is built
into the HTML reader.

NS: If you copy a math fragment, you will need the style sheet for MathML
if it wants to use CSS. NS said that people do not copy math with CSS in it
because the CSS was not used in the copying process.

NS: If we deprecate mstyle, what do we do instead?

DC: Mstyle is equivalent to an mrow. Mstyle acts as a container and can
hold children.

NS: Mstyle is not written to be compatible with core.

DG: Can we find one vendor who would like to render math in a CSS
independent way? It would be good for us to find a customer before we do
the work.

DC: If we are going to deprecate mstyle, we need to do it immediately after
Christmas.

NS: Mstyle is used a lot. NS says we cannot deprecate it in full. We may
not have to support it for all the arguments used outside of core.

DC: In core mstyle can be aliased to mrow.

NS: We do not have to decide to deprecate mstyle now. We can take it up in
the beginning of next year after people had a chance to comment on the
issue.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.0-rc3#cp-md-0-3-changing-a-href-https-github-com-w3c-mathml-core-issues-180-columnspan-to-colspan-a-to-align-with-html-tables-in-core-in-full->3.
Changing columnspan to colspan
<https://github.com/w3c/mathml-core/issues/180> to align with HTML tables
in core? In full?

NS: MathML tables are more powerful than HTML tables.

NS: In MathML we use rowspan and columnspan. In HTML, it is rowspan and
colspan. In core it would be easier if columnspan was dropped in favor of
colspan.

SD: He looked at MathML 3, and asked this question: If we're going to look
at Column Span versus call Span, what do we do with the attributes such as:
ColumnAlign, ColumnWith, ColumnSpacing, and Columnlines?

NS: said that they are not supported in core.

DG: Why not keep both columnspan and colspan until things clarify?

DC: We must do code checks on both. This can be a pain if both are used in
the same document.

DC: We should change columnspan to colspan.

DG: Do not we have the same case when we use MathColor and StyleColor?
Which attribute comes first?

NS: MathColor was specifically named differently than Font color because it
was meant not to be stylistic.

DC: We should ask the implementers what we should do.

NS: Fred was willing to say we can remove column span from core.

DC: Having to manage two "column" parameters would not be popular with
developers.

NS: prefers to rename ColumnSpan. In MathML 4 we might have to rename the
other column attributes.

NS: We could say that attributes with column in their names are not in core.

DG: It is a cosmetic change and does not really matter.

NS: *ACTION* Ask Fred what to do with the columnspan attribute.

DC: We have no conclusion. We are supporting core to CR. We cannot change
attributes after that.

NS: If Fred thinks that it is a bad idea to support both columnspan and
colspan, then we go with colspan.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.0-rc3#cp-md-0-should-we-deprecate-mathvariant->Should
we deprecate mathvariant?

NS: Said that Fred said that math variant as failing a ton of tests,
because they didn't want to bring it into CSS. He would be very happy to
just drop mathvariant, other than mathVariant equals normal and force
people to use the Appropriate Unicode numbers.

NS: In core, let us get rid of mathvariant except for mathvariant equals
normal.

DC: No one is going to get this correct. Describing what you can do takes
pages.

NS: Fred prefers to drop mathvariant from core, except for mathvariant
equals normal.

DG: He has had problems with making MathVariant work. Even if it is kept,
it causes confusion. He does not know if it is good to remove it.

NS: does not know what CSS can do to the Unicode equivalent of MathVariant.

BM: If you try a Unicode block and try to change it with CSS, he is not
sure what you get.

PI: He wanted to distinguish logical classes of token elements. He use font
changes to do this. He wanted to show that certain characters were
different things, not just stylistic changes.

MUS: We do need mathvariant for the single letter ascii Case.

NS: We need it for mathvariant equals normal.

DC: Dropping it from core makes sense. Full stays unchanged. we need to do
this now if we are going to change something.

NS: Does anyone want to hold off?

DG: votes with BM.

BM: Mathvariant is not going to work so get rid of it.

NS: *ACTION* NS will open an issue specifically on mathvariant and say the
sentiment of the Working group is that it is a good thing to get rid of
mathvariant in core.

Our next meeting will be on January 5, 2023.

NS: asked people to make mstyle comments to help resolve the mstyle
deprecation issue.