Minutes: MathML Full meeting 30 Jan, 2025

 Attendees:

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

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

*Action Item:* BM: I just wanted to report a minor progress item. I had an
action item to add a code PIN example on the subject of situations where we
should get stretchiness, where we currently don't in core. So I added a
codepen link to the issue under MathML core How is inline stretch size
constraint determined? #270 <https://github.com/w3c/mathml-core/issues/270>.
I invite people to give me their opinions on these codepens.
<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>

(last chance unless someone re-opens the issue?)

*Resolution:* The large operator property will be called "largeop".
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-4-a-href-https-github-com-w3c-mathml-issues-385-385-comments-on-chapter-3-a->4.
#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-5-a-href-https-github-com-w3c-mathml-core-issues-279-279-core-clarify-the-language-around-deprecated-features-of-mathml-a->5
#279 (core) Clarify the language around deprecated features of MathML
<https://github.com/w3c/mathml-core/issues/279>

*Action Item:* NS suggests that we try to implement some of the items in
issue 279 across browsers.

*Action Item:* NS will copy the list in 279 into a comment in 279, and
everyone can look at the list and make comments on every item on which they
have an opinion.
<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

BK said that the plan discussed in the core meeting of January 27, 2025,
concerning MathML full, to take a look at what should be deprecated, or
listed as experimental, had been agreed upon. We will discuss this today in
issue #279 (core) Clarify the language around deprecated features of MathML
<https://github.com/w3c/mathml-core/issues/279>.

PL: Mphantom will be removed by the sanitizer.

NS: Well, there are 2 points. One is, nobody uses the sanitizer at the
moment, and it's not clear it will get used, and 2 if they do use it on a
site like Github, they could turn off the sanitizer defaults.

NS: If mathML were declared to be special, then the sanitizer would
eliminate it.

DC: Interpreting a PDF Structure Tree as XML
<https://github.com/latex3/tagging-project/discussions/789> generates xml
from pdf.

DC: So this is uploading a Pdf, and it generates the internal tag structure
which includes in these examples, math, and MathML.

DC: The Pdf structure tree is an annotated tree. So it's a bit like Xml.
But it's sort of completely different. In particular, the attributes are
structured so they're far more like Xml elements than Xml attributes that
can have a string. So you have to model them somehow. And it's not
specified what you're supposed to do. So yes, I've made something up. You
have to make something up for all attributes.

*Action Item:* BM: I just wanted to report a minor progress item. I had an
action item to add a code PIN example on the subject of situations where we
should get stretchiness, where we currently don't in core. So I added a
codepen link to the issue under MathML core How is inline stretch size
constraint determined? #270 <https://github.com/w3c/mathml-core/issues/270>.
I invite people to give me their opinions on these codepens.
<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?)

No updates.
<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>

(last chance unless someone re-opens the issue?)

*Resolution:* The large operator property will be called "largeop".

Mus: I can say what my program is currently doing. I had to distinguish
between largeOP and large OP. Expression, because I have the concept of
largeOP Expression, which is the whole thing, whereas the operator itself
is just a single character, and I need to distinguish between the two.

MuS: When I approach an integral by moving character by character, and I
come up with an integral expression, I say, integral expression. I actually
look at the character inside the integral expression which is in an mrow
with an intent. And so I look inside there, and I find out what the
character is. And then I have a dictionary that says how to say that
character, and so I say that character followed by the word expression. And
then, as I navigate into this expression, which is an mrow and I run into
the actual symbol, which is the 1st child, and I speak it. And so, if I
had, the integral from 0 to infinity or something or other, I'd at the
beginning, at the at the Mrow, I would say integral expression, and then I
go integral, so that you know there's a difference between the two.

From Deyan Ginev to everyone: ... continues to look much cleaner to me.
Need to get back to the aliasing issue at some point and alias properties.

BM prefers using mrows.

NS: So you prefer that the largeop property goes on the integral sign and
not the operand of the integral?

MuS: Yes.

MuS: I have done a minor redefinition, because I have an mrow concept for
things like integral expressions, functions, and mfences. I think it is
important for speech and typography.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-4-a-href-https-github-com-w3c-mathml-issues-385-385-comments-on-chapter-3-a->4.
#385: comments on chapter 3 <https://github.com/w3c/mathml/issues/385>

(new thoughts on how to handle examples?)

NS: What are we going to do with all the examples?

NS: Incompatible browsers make polyfills not work. Do we revert to images?
DC was going to see how they look currently.

No updates.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-5-a-href-https-github-com-w3c-mathml-core-issues-279-279-core-clarify-the-language-around-deprecated-features-of-mathml-a->5
#279 (core) Clarify the language around deprecated features of MathML
<https://github.com/w3c/mathml-core/issues/279>

In issue #279, NS Writes: There are really two related specs (core and
full), but MDN doesn't seem to have a way to deal with that: "deprecated"
and "experimental" don't fully make sense in this situation. As an example,
mfrac.numalign is very much in MathML full, but not in MathML core because
one can (in theory) use CSS to do the alignment.

CSS support is not fully implemented in Firefox and Safari. Additionally,
it is not clear how CSS will interact with the math layout rules which has
its own "math inline" and "math block" rules. Because of these two things,
many people felt that maybe some additional text is needed for many of the
items to clarify the core/full difference and explain the limitations.

As per the 30 Jan Math WG meeting, issue #279 is a workspace for people to
add their thoughts about how each item should be classified. Two options
are "deprecated" and "experimental". The meeting consensus was that there
may need to be other options.

In issue #279, captainbrosset wrote: These remaining MathML features are
all marked as deprecated by BCD (browser compatible data))
<https://github.com/mdn/browser-compat-data> (the data source that MDN uses
for compatibles).)

DC: For some of them, We need to clarify about polyfills. The MDN. It is
mostly aimed at authors. So if it's deprecating, it's saying you shouldn't
use them.

DC: So the question is, should somebody be generating MathML using mfence
which is full of polyfills but not in core.

NS: We want people to generate core when possible.

DG: In MathML3 we did not have core and full like we do in MathML4. We
could say that items, in full but not core, are experimental.

BM: It could be a problem on the MDM side not being able to distinguish
full from core.

NS: There are things in HTML that are called presentational hints. They're
widely used, but not supposed to be used.

NS: Display style is one, and math color was another.

NS: Math color must be a value that is a color. In that case the user agent
is expected to treat these attributes as a presentational hint, setting the
elements, color, and background properties to the corresponding values.

BM: Presentational hint, in general, applies to many of the things that got
emitted from core, but not everything.

BM: We need words to describe something that is in full but not core.

BM: In any case, I wouldn't categorize mfence as a presentational hint.
That seems kind of stretching too far.

NS: Not sure what MDN does with presentational hints.

MUS: MDN has math color deprecated. MUS wants this fixed.

DG: MDN is web facing and thinks that things should be deprecated if they
are not used on the web.

NS: We basically have these 3 options. They're in there. They're
experimental, or they're deprecated. We need to go through the list and
decide on each element.

DG: So there's this gray zone where it's not yet deprecated. It's not yet
experimental. We're thinking about it. We really don't have anything to say
about them in MDN that's productive.

NS: Numalign is useful but probably will never be added to core. Numalign
aligns numerators, and that could be done with CSS.

Mus: Mathcolor works fine in all browsers. It should not be deprecated. The
core spec says it should be deprecated which causes MDN to say it should be
deprecated.

Ns: MDN is about the web and not about Word.

BM: We tend to look at MathML core as a new subset, whereas from a web or
MDN viewpoint, core is a replacement for MathML3.

From Deyan Ginev to everyone: MDN annotation language is described here:
https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Experimental_deprecated_obsolete

NS: Let us go down the list and talk about them. Put them into categories:

   1. It's in there.
   2. As experimental.
   3. It's in there as deprecated.
   4. It's in there, in this new mode, that we maybe want to have a
   paragraph that says, not in core, but in full. Use CSS, when in the web
   context and use this when you're out of the web context.

list with comments

   - mathml.elements.maction

NS: It actually accepts action type and selection. It does not define any
behavior and just treats it as an mrow element. It's in core but ignored.

DC: Deprecate, it does not do anything.

NS and DC: It provides a place for someone to hang their JavaScript off of.

DG: So I would argue, it's also not experimental, because there's no desire
for anybody to add custom JavaScript, or behavior carrying elements.

DG: So it's probably more deprecated than it is experimental. But yes, it's
not either of those.

NS: This is one of our new categories: needs MDN change not deprecation.

DG: So you have both the hope and the intention that this will land in the
web platform natively one day.

DC: I think we can't decide on the 1st one. We should maybe look at
something else.

   - mathml.elements.maction.actiontype
   - mathml.elements.maction.actiontype.toggle
   - mathml.elements.maction.selection
   - mathml.elements.mfenced
   - mathml.elements.mfrac.denomalign

NS: We can align the numerator and denominator: left, center, or right.
Because you can do this with CSS numalign and denomalign are not part of
core. These are presentational things. They are not attributes.

NS: I do not know how well implemented they are.

DC: It is not easy to do with CSS.

DG: It would be great if we treated CSS Support as experimental. Actually,
in the MDN. Terminology and MathML, plus CSS as experimental.

*Action Item:* NS suggests that we try to implement some of the items in
issue 279 across browsers.

DG: Given limited time and limited people, it would be much nicer to spend
our efforts, getting CSS. Support to work perfectly and be tested rather
than fighting for attribute names.

NS: So, in some sense, I'd say this, this would be what the spec calls a
presentational hint.

NS: How do we proceed?

*Action Item:* NS will copy the list in 279 into a comment in 279, and
everyone can look at the list and make comments on every item on which they
have an opinion.

   - mathml.elements.mfrac.linethickness.named_spaces
   - mathml.elements.mfrac.linethickness.nonzero_unitless_values
   - mathml.elements.mfrac.linethickness.thin_medium_thick
   - mathml.elements.mfrac.numalign
   - mathml.elements.mfrac.numalign
   - mathml.elements.mmultiscripts.subscriptshift
   - mathml.elements.mmultiscripts.superscriptshift
   - mathml.elements.mo.named_spaces
   - mathml.elements.mo.nonzero_unitless_values
   - mathml.elements.mpadded.named_spaces
   - mathml.elements.mpadded.nonzero_unitless_values
   - mathml.elements.mpadded.pseudo_units
   - mathml.elements.mpadded.scale_factor
   - mathml.elements.mspace.named_spaces
   - mathml.elements.mstyle.background
   - mathml.elements.mstyle.color
   - mathml.elements.mstyle.fontsize
   - mathml.elements.mstyle.fontstyle
   - mathml.elements.mstyle.fontweight
   - mathml.elements.msub.subscriptshift
   - mathml.elements.msubsup.subscriptshift
   - mathml.elements.msubsup.superscriptshift
   - mathml.elements.msup.superscriptshift
   - mathml.elements.mtable.width.named_spaces
   - mathml.elements.semantics.advanced_visible_child_selection
   - mathml.global_attributes.mathbackground
   - mathml.global_attributes.mathcolor
   - mathml.global_attributes.mathsize
   - mathml.global_attributes.mathsize.named_spaces
   - mathml.global_attributes.mathsize.nonzero_unitless_values
   - mathml.global_attributes.mathsize.small_normal_big

end list