Minutes: MathML Full meeting 16 Jan, 2025

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Deyan Ginev
   - Bert Bos
   - Patrick Ion
   - Bruce Miller

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

   - Murray Sargent

<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

PL: Discussed core issue #227 MathML support in the HTML Sanitizer
<https://github.com/w3c/mathml-core/issues/227>. He is working on elements
that should be in the sanitizer (
https://w3c.github.io/mathml-docs/mathml-safe-list). He invites others to
look at this list. He would like the sanitizer to remove the mphantom
element because it has hidden contents which could cause problems.

*CONSENSUS* The group decided against removing mphantom as part of the
sanitizer.
<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?)

*CONSENSUS* DC: We will deprecate maligngroup and malignmark it and handle
special cases with polyfills. DC will write this up. Issue 181 will be left
open.
<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>

(new thoughts on the property name?)

No updates.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-4-a-href-https-github-com-w3c-mathml-issues-433-433-comment-include-or-not-a-sample-set-of-default-conversion-from-plain-mathml-to-mathml-with-intent-a->4.
#433 (comment) include (or not) a sample-set of default conversion from
plain-MathML to MathML-with-intent
<https://github.com/w3c/mathml/issues/433>

(discuss need for "Common" for "intent-default")

*ACTION* NS will add text to the Core Intent Property List
<https://w3c.github.io/mathml-docs/intent-core-properties/#Inference>
describing his proposal.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-5-a-href-https-github-com-w3c-mathml-issues-425-425-39-intent-39-should-be-specified-as-translatable-a->5.
#425: 'intent' should be specified as translatable
<https://github.com/w3c/mathml/issues/425>

*ACTION* DC will say that intent cannot be translated because it is not a
natural language. He will close issue 425.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-6-a-href-https-github-com-w3c-mathml-issues-385-385-comments-on-chapter-3-a->6.
#385: comments on chapter 3 <https://github.com/w3c/mathml/issues/385>

(new thoughts on how to handle examples?)

Continue this discussion next week.
<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

NS: There are 13 issues which are really not issues at the moment. They're
labeled MathML next, so we'll get to them some other time.

Ns: There are 10 that are spec updates. That's not great, but it means that
we've addressed these and we just need to do the work of doing the updates.

NS: There are five that need a polyfill with two overlapping also needing a
spec update. So again, they have been dealt with except for writing some
code.

NS: There are seven issues left to be decided. These seven issues are on
today's agenda.

NS: After that comes the horizontal review and CR.

PL: Discussed core issue #227 MathML support in the HTML Sanitizer
<https://github.com/w3c/mathml-core/issues/227>. He is working on elements
that should be in the sanitizer (
https://w3c.github.io/mathml-docs/mathml-safe-list). He invites others to
look at this list. We will consider this list in the core meeting on Monday
January 27, 2025. He would like the sanitizer to remove the mphantom
element because it has hidden contents which could cause problems.

BB: Browsers do not remove it.

DG wrote: "What's wrong with ? That is just an , isn't it? The MathML Core
spec has a note: ""The element is primarily intended as an aid in aligning
expressions. ""

Sanitizing that away would quietly break content, wouldn't it? Shouldn't it
get at least marked as deprecated if so? "

NS: If you sanitize it, you can't just remove it, because then you don't
have the right number of children for some elements.

*CONSENSUS* The group decided against removing mphantom as part of the
sanitizer.
<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?)

DC Wants to deprecate maligngroup and malignmark because CSS can replace
their functionality.

From Deyan Ginev to everyone: float: right does not change any of the DOM
properties, so the tree structure (and accessibility tree) are the same

*CONSENSUS* DC: We will deprecate maligngroup and malignmark it and handle
special cases with polyfills. DC will write this up. Issue 181 will be left
open.
<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>

(new thoughts on the property name?)

No updates.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-4-a-href-https-github-com-w3c-mathml-issues-433-433-comment-include-or-not-a-sample-set-of-default-conversion-from-plain-mathml-to-mathml-with-intent-a->4.
#433 (comment) include (or not) a sample-set of default conversion from
plain-MathML to MathML-with-intent
<https://github.com/w3c/mathml/issues/433>

(discuss need for "Common" for "intent-default")

NS: We need to provide the AT with defaults. What should the defaults be?

In issue 433, NS wrote: "First off though, note that I strongly feel there
needs to be a math level (or higher) attribute that controls defaulting
behavior so that legacy documents can be interpreted with the knowledge
that the authors were not able to make use of intent (hence, AT can infer
whatever it feels is appropriate). I proposed an attribute intent-default
with the following values: - legacy (default) -- AT is free to apply any
heuristics they want - structure -- speak the structure - common -- speak
the common interpretation in lower level math Note: in all cases, if intent
is given, it should be used (if appropriate). Even for legacy, it is
possible remediation may have added an intent value."

The group decided that, instead of "structure", we would use the term
"literal".

DC considered the term x squared without and intent. Intent would be
undefined. You would fall back on a system-specific default.

DC: My suggestion is that we do specify the common speech output.

NS: Common is not recognized. So what you are doing is to fall back on what
MathPlayer did.

DC: You could call this set of defaults as MathCAT-common.

DC: You cannot make the vender property the default; therefore, you make it
undefined.

DG: Keeping the current undefined behavior is preferrable.

DG: I have three different objections to having a default for all MathML
elements without an intent.

The first objection as by default it will be broken for archive Because we
are almost entirely outside of common.

The second objection is that we haven't finished defining common. I think
that it's really healthy to define a common property and have it as a
property that you select with intent.

And the 3rd problem that has occurred to me since the Github discussion is
that it's actually a bit of an anti-competitive move to move a MathCAT
default readout to be the ubiquitous MathML readout in the sense that you
can no longer experiment with any other at to make better readouts, because
if you don't comply with the default readouts, you're just not complying
with the spec, and I think that is kind of highly problematic. So we would
need to have an intent overwrite just to allow other ATS or MathCAT itself
to do more experimental things and not the common behavior.

NS: My original proposal is that we have what is called "intent-default",
and that there were 3 values with the default being legacy which I think it
kind of has to be, because you have all the old documents that nobody ever
put anything on. And so they just do what they do, and no one has a chance
to say anything. But I did also propose "literal", at the time called
"structure", and then "common", which is the one I think a lot of systems
would like to use, because then they don't have to provide intent because
they can be assured of what the readout would be.

NS: I agree with Deyan that you can't make the default common because all
these documents that exist already didn't even know about that.

NS: By the same token, those that don't implement intent aren't going to
implement common.

DC: So for a long time, most MathML is not going to have intent on.

DG: I would also be mostly in favor of legacy as the default.

DC doesn't want all his work on intent to be for nothing.

DC Pointed out that 99% of all MathML would be unspecified.

Ns: It was always the case that intent would be an optional thing, that
people can add to clarify how something should be read and.

DG: When common becomes established, it can be the default after a trial
period.

DC We will accept an updated version of NS's original proposal made in 2023.

*ACTION* NS will add text to the Core Intent Property List
<https://w3c.github.io/mathml-docs/intent-core-properties/#Inference>
describing his proposal.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-5-a-href-https-github-com-w3c-mathml-issues-425-425-39-intent-39-should-be-specified-as-translatable-a->5.
#425: 'intent' should be specified as translatable
<https://github.com/w3c/mathml/issues/425>

DG: The translation property was not defined for MathML. concepts and
literals are different.

DG: Translating "sin" into other languages doesn't work well.

NS: We can propose that all MathML elements should have no translation to
be the default except for Mtext and alt-text.

DC: The intent attribute has its own formal grammar and would not survive
automatic translation.

DC suggested that, in the spec, we do not have to say anything about
translation.

Ns: We can say that intent is so complicated we don't think it's practical
for anybody to try and uh do auto translation for it.

*ACTION* DC will say that intent cannot be translated because it is not a
natural language. He will close issue 425.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-6-a-href-https-github-com-w3c-mathml-issues-385-385-comments-on-chapter-3-a->6.
#385: comments on chapter 3 <https://github.com/w3c/mathml/issues/385>

(new thoughts on how to handle examples?)

NS: What are we doing for the examples in the spec? Can we use MathML, or
do we insert images in the spec?

DC: In the actual spec, the images are not there.

DC: It just has displays that don't match the description of examples.

NS: Should we revert to images?

We will resume this discussion next week.