Minutes: MathML Full meeting 3 April, 2025

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Murray Sargent
   - Deyan Ginev
   - Paul Libbrecht
   - Bruce Miller
   - Moritz Schubotz

Action Items
<https://cryptpad.fr/#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

*ACTION* NS will not be here for the April 10, 2025, intent meeting.
NS will provide an agenda for the April 10, 2025, intent meeting.
DC will chair the April 10 meeting.

*ACTION* NS will contact BK about a possible Monday, April 14, 2025, Core
meeting.
<https://cryptpad.fr/#cp-md-0-2-a-href-https-github-com-w3c-mathml-issues-528-528-remove-continued-row-from-core-properties-a->2.
#528: Remove :continued-row from Core properties
<https://github.com/w3c/mathml/issues/528>

(can this be closed?)

DC closed issue 528 without any action.
<https://cryptpad.fr/#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-120-120-remove-deprecate-simplify-the-ms-element-a->3:
#120: Remove/deprecate/simplify the ms element
<https://github.com/w3c/mathml/issues/120>

(both core and full -- where are we on this -- recent update?)

*action* issue 120 will be deferred to the next core meeting.
<https://cryptpad.fr/#cp-md-0-4-a-href-https-github-com-w3c-mathml-issues-524-524-naming-the-arguments-to-intent-new-property-needed-a->4
#524:Naming the arguments to intent: new property needed?
<https://github.com/w3c/mathml/issues/524>

*ACTION* NS: We have not resolved issue 524. We will come back to it.
<https://cryptpad.fr/#cp-md-0-4-5-a-href-https-github-com-w3c-mathml-core-issues-142-core-issue-142-should-all-mathml-elements-really-be-potential-hyperlinks-a-linking-in-mathml-core>4.5
core issue 142 Should all MathML elements really be potential hyperlinks
<https://github.com/w3c/mathml-core/issues/142> linking in MathML Core

*ACTION* Bring up issue 142 in the next core meeting.

*ACTION* DC has a draft of a pull request for issue 142 on which he is
working. People are invited to comment.
<https://cryptpad.fr/#cp-md-0-5-anyone-willing-to-take-on-some-spec-or-code-writing-tasks->5.
Anyone willing to take on some spec or code writing tasks?

There are 9 open issues with the "needs spec update" label.
<https://github.com/w3c/mathml/labels/need%20specification%20update>

DC is working on: Make MathML attributes ASCII case-insensitive Issue #178
<https://github.com/w3c/mathml/issues/178>

*ACTION* DG: Not next week, but I am willing to go through the attributes
to see if they are case insensitive.
<https://cryptpad.fr/#cp-md-0-agenda>Agenda
<https://cryptpad.fr/#cp-md-1-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

*ACTION* NS will not be here for the April 10, 2025 intent meeting.
NS will provide an agenda for the April 10, 2025, intent meeting.
DC will host the April 10 meeting.

*ACTION* NS will contact BK about a possible Monday, April 14, 2025, Core
meeting.
<https://cryptpad.fr/#cp-md-0-dc-made-a-pr-for-a-href-https-github-com-w3c-mathml-issues-181-issue-181-mathml-4-extensions-for-alignment-and-possible-deprecation-of-maligngroup-and-malignmark-a->DC
made a PR for issue #181: MathML 4 extensions for alignment and possible
deprecation of (maligngroup/) and (malignmark/)
<https://github.com/w3c/mathml/issues/181>

Draft PR 532 for maligngroup <https://github.com/w3c/mathml/pull/532>
<https://cryptpad.fr/#cp-md-1-2-a-href-https-github-com-w3c-mathml-issues-528-528-remove-continued-row-from-core-properties-a->2.
#528: Remove :continued-row from Core properties
<https://github.com/w3c/mathml/issues/528>

(can this be closed?)

DC closed issue 528 without any action.
<https://cryptpad.fr/#cp-md-1-3-a-href-https-github-com-w3c-mathml-issues-120-120-remove-deprecate-simplify-the-ms-element-a->3:
#120: Remove/deprecate/simplify the ms element
<https://github.com/w3c/mathml/issues/120>

(both core and full -- where are we on this -- recent update?)

*action* issue 120 will be deferred to the next core meeting.
<https://cryptpad.fr/#cp-md-1-4-a-href-https-github-com-w3c-mathml-issues-524-524-naming-the-arguments-to-intent-new-property-needed-a->4
#524:Naming the arguments to intent: new property needed?
<https://github.com/w3c/mathml/issues/524>

DC wrote: When navigating 2D structures with AT, it is very common to name
the part of the expression to which one has navigated. For example, if you
have a fraction, then when you "zoom into" the fraction, you will often
hear "in numerator" and/or "end numerator" when leaving it. Same for the
denominator. For "msup", "base" and "superscript" (or "exponent") might be
used. If an intent is given that is not in core, there is no way for AT to
use a concept-specific name when navigating. As an example of how one could
handle this, one could add something like ":navname-xxx" to the arguments.
As an example

In this example, the user might hear "fraction-like of a and b end
fraction-like" when listening to the expression. If they decide to navigate
into it, they might hear "in num, x". Moving right, they might hear "out of
num, in denom, y". Without the names, they might hear some generic phrases:
"in arg 1" and "out of arg 1, in arg 2 y". That's not ideal, especially
when you have nested expressions so that there several "arg 1"s, etc.

NS: If you have an open concept, shouldn't there be a way to name each
argument? The alternative is to number the argument, arg1, arg2, you really
need a unique way to distinguish each argument. This is for 2D equations.
In linear cases use a comma.

NS: If it's a binomial or permutation, how does the listener know you have
moved from one term to another?

DC: If it is an unknown function, how do you name the parts.

BM: This could be encoded in the core, or open, dictionary.

DC: If it's an unknown function, what do you use instead of numerator and
denominator in the speech?

NS: Is there a way in intent or something elsewhere the user or the author
can provide information to the AT as to what to say?

BM: I suggest that this might be something to be encoded in the dictionary,
whether core or open. But that would allow the common cases, but it doesn't
provide an option for one of David's unknown cases.

DC: This would only work for names known to the system.

DC: The solution that always works is to call them as you see them: first
argument, second argument… and don't name them.

DG: It is harder to make new entries in the core list because the
requirements for the core list are growing.

PL: So I was thinking of a simple syntax that said this is the argument.
When you have this intent on the function, then you can have the arguments
which you made. This is the place where you set it up, and then have some
syntax, like a colon, which says this is the role of this thing.

$x:numerator $y:denominator.

PL: We should not make this mandatory.

NS summarized with three options: Option One, do nothing.

option two, AT uses a name where it has a name, otherwise it uses a number.

Option three is on the referenced property that says you should be using
that reference for that argument name as the part.

*ACTION* NS: We have not resolved issue 524. We will come back to it.

we will come back to this.
<https://cryptpad.fr/#cp-md-1-4-5-a-href-https-github-com-w3c-mathml-core-issues-142-core-issue-142-should-all-mathml-elements-really-be-potential-hyperlinks-a-linking-in-mathml-core>4.5
core issue 142 Should all MathML elements really be potential hyperlinks
<https://github.com/w3c/mathml-core/issues/142> linking in MathML Core

Emilio Cobos Álvarez wrote: href can be used to establish the element as a
hyperlink to the specified URI. This in Gecko has implications and behaves
the same way as <a> or <area>. Two things: Is this feature used / desired /
worth it? Links are complex. If it is, should it really match :visited? I
think in WebKit it does not if I'm reading the code correctly.

DC: So this is whether to have href on Mrow, or add a new, <a> element. The
people from the browser community really want to have a new <a> element.

DC: href on mrow works everywhere while <a> does not work anywhere.

DC: SVG has added an <a> element.

From Moritz Schubotz to everyone: I’m also having this problem. From my
perspective it’s just annoying to implement both

DC: People are saying SVG and HTML have <a> why not MathML?

DC: There is a complete compatibility break.

NS: I thought the w3c does not like breaking compatibility. If you take
away stuff that is working, people will not like it.

MuS: I don't guess that people really know that MFenced does have a
property that isn't being emulated by the Mrow, and that is increasing the
size of the brackets as you work your way out from the innermost, and
that's the way it works in the office math.

MuS: For example (((A + B))) The outer parentheses are larger than the
inner parentheses.

NS: This is not in the spec.

MuS: It is not in the spec, but it is nice.

DG: I suspect Murray's example can actually be made to work in MathML core
with adding some padding, because then it will stretch over the padding and
have the same visual appearance. So there's a way Css. Helps

MuS: Yeah, but you'd have to really work at it.

From Moritz Schubotz to everyone: in Wikipedia we use <a> and convert it to
href for MathJax as it does not support it

DG: I wanted to caution everyone. There is an actual outcome which is the
only outcome I worry about of not having any links in MathML core. So if it
comes down to <a> or nothing, I think <a> is the better outcome. If you can
get them to have href with <a> well all the better.

*ACTION* Bring up issue 142 in the next core meeting.

*ACTION* DC has a draft of a pull request for issue 142 on which he is
working. People are invited to comment.

From Deyan Ginev to everyone: Replying to "https://github.com/w..."

interesting

From Deyan Ginev to everyone, You could keep the MathML in modern browsers
and do document.querySelectorAll( 'math *[href]' ) t..., Press F6 to focus
on pop out bubble window

From Deyan Ginev to everyone: Replying to "https://github.com/w..."

example: https://codepen.io/dginev/pen/pvoGdXe
<https://cryptpad.fr/#cp-md-1-5-anyone-willing-to-take-on-some-spec-or-code-writing-tasks->5.
Anyone willing to take on some spec or code writing tasks?

There are 9 open issues with the "needs spec update" label.
<https://github.com/w3c/mathml/labels/need%20specification%20update>

DC is working on: Make MathML attributes ASCII case-insensitive Issue #178
<https://github.com/w3c/mathml/issues/178>

NS: So Fred must have written some language into the core spec that we
could maybe copy over into the main spec. DC: There are more attributes in
full than in core, so more work.

*ACTION* DG: Not next week, but I am willing to go through the attributes
to see if they are case insensitive.