RE: Minutes: MathML Full meeting 15 Dec, 2022

Thank you Neil for your kind words.

I want to express my appreciation for the technical discussions I have with the group members to help me understand the topic.



Regards
Louis Maher
Phone: 713-444-7838
Email: ljmaher03@outlook.com

From: Neil Soiffer <soiffer@alum.mit.edu>
Sent: Saturday, December 17, 2022 12:28 AM
To: www-math@w3.org
Subject: 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

Regrets

  *   David Farmer
  *   Cary Supalo

Agenda
1. Announcements/Updates/Progress reports

DG: The MathML archive is ready for release around January 8, 2023. MathML should work on chrome and edge.

2. Deprecating mstyle in core?<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fmathml-core%2Fissues%2F181&data=05%7C01%7C%7C544b057f1503412fd97908dadff80a75%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638068553663291326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SB0IN6XJRj9SKp3pvLJmEKm89fx9kmGZ30wROWyGB18%3D&reserved=0> 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.

3. Changing columnspan to colspan<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fmathml-core%2Fissues%2F180&data=05%7C01%7C%7C544b057f1503412fd97908dadff80a75%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638068553663447552%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1xv0mdfOuGMbNZae6OuIQrUUGg165q4ne1LfjEBnxIA%3D&reserved=0> 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.

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.