RE: Minutes: MathML Full meeting 3 April, 2025 Correction

Hello,

David Carlisle does not have a pull request to discuss on MathML-core issue 142

https://github.com/w3c/mathml-core/issues/142

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

From: Neil Soiffer <soiffer@alum.mit.edu>
Sent: Saturday, April 5, 2025 12:38 AM
To: www-math@w3.org
Subject: 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
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.

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.

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.

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.

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.

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.

Agenda
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.

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>

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.

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.

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.

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

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.