Minutes_ MathML Core meeting _ 24 May_ 2024

05/24/2024 <https://github.com/w3c/mathml-core/issues/243>   MathML Core Meeting

Attendees

  *   Brian Kardell
  *   Neil Soiffer
  *   Louis Maher
  *   Bruce Miller
  *   Deyan Ginev

Regrets

Action Items

  *   Define Accessibility Mappings for MathML Elements #196<https://github.com/w3c/mathml-core/issues/196> ACTION NS will create an issue to include menclose as a level two item.
  *   Specify empty (mo) treatment #209<https://github.com/w3c/mathml-core/issues/209> RESOLUTION/ACTION: NS will change a line in the spec to say that if the (mo) has no content, that it generates spacing zero and returns category K.
  *   [interop] Text fragments + MathML #240<https://github.com/w3c/mathml-core/issues/240> ACTION DG: This is an opportunity to provide guidance on how MathML should be handled by this algorithm. BK: First make a test to see if you know how the algorithm works. If there is a bug, if so, open an issue on their repro.
  *   Define that (and how) glyph assemblies are mirrored in rtl formulas #235<https://github.com/w3c/mathml-core/issues/235> RESOLUTION/ACTION BK will talk to BB to see what we are required to do for the I18 review because we are not ready to handle some of these challenges.

Agenda Items
Announcements/Updates

The June core meeting will be held on Thursday, June 27, 2024, at our regular time. This meeting will be a combined core and intent meeting. The total meeting time will be one hour.

Checking on issues:

  *   Define Accessibility Mappings for MathML Elements #196<https://github.com/w3c/mathml-core/issues/196>

Brian poked Valerie who is co-chair of ARIA. They are merging the ARIA specs into a single repo. The AIM-MathML repo is part of that.

NS is free to make changes. He cannot merge yet but will be able to do so when he becomes a n editor.

NS: will the accessibility mappings be for core or for the full MathML?

BK: For the core.

NS: The mappings will only be used in browsers.

NS: The core does not do everything like menclose.

Ns: Safari and Firefox support menclose. You can do menclose with CSS. Menclose is not part of core. It might be added to core because CSS is complicated.

NS: It might be added as a level two item.

ACTION NS will create an issue to include menclose as a level two item.

  *   Specify empty (mo) treatment #209<https://github.com/w3c/mathml-core/issues/209>

DG: The important breakthrough I had with this issue is that the clarification that an empty (mo) can often be considered an invalid element in certain workflows. But it is also, as Murray suggests, something that could happen during editing as part of an editing workflow. So, my use of an empty (mo) that they open the issue with was instead a placeholder where you do not know what the operator is. It is something invisible. So, you do not want to add a character, so that those are 3 different situations in which you may have an empty (mo).

NS Do we allow an empty (mn) and an empty (mi)?

DG: These are valid but not encouraged.

NS: I think a lot of people have used an empty (mrow) as a placeholder.

DG: The specific issue I had was spacing, and the idea is that for one reason or another, there is default spacing that is visible.

DG: So, an empty (mo) currently adds visible space. And my outstanding request for the issue is, is there any sort of technical way or spec way to say an empty (mo) should have 0 left and right spacing so that it shows no spacing?

DG: We do not use an empty (mo) officially. So, we have not actually changed our generator to using empty (mo)s. We are using an invisible Unicode character. So, it is now a low priority thing on our side because we are not going to use it. But I still think it is correct to have it invisible because it is empty.

NS: Putting in a space for an invisible symbol will affect Braille.

DG: Since I have a workaround, I am even happy to say, if this does not have an obvious move forward, we can push it down to level 2 or something like that, because it is now a low priority thing.

NS: I see that Fred has pushed this into issue 218<https://github.com/w3c/mathml-core/issues/218>.

DG: Well, that is the more forward-thinking suggestion. He wanted to have a CSS mechanism to tweak lspace and rspace that is independent of the attributes, and that is fine, but it is a separate mechanism.

DG thinks the default is wrong.

NS: Fred does not want to change the dictionary.

DG: Fred wanted to change the category to Category K in this case, and that sounded like something that does not touch the dictionary, but touches the spec, and that is something that I liked.

RESOLUTION/ACTION: NS will change a line in the spec to say that if the (mo) has no content, that it generates spacing zero and returns category K.

  *   [interop] Text fragments + MathML #240<https://github.com/w3c/mathml-core/issues/240>

In the issue, DG writes: The URL Fragment Text Directives<https://wicg.github.io/scroll-to-text-fragment/> effort defines an algorithm "find a range from a text directive"<https://wicg.github.io/scroll-to-text-mmfragment/#find-a-range-from-a-text-directive> which is applicable over nodes. I find the following quote to be a great summary: The basic premise of this algorithm is to walk all searchable text nodes within a block, collecting them into a list. The list is then concatenated into a single string in which we can search, using the node list to determine offsets with a node so we can return a range. I am opening this issue to discuss if "a block" is a concept that needs to be extended/refined when that algorithm is executed inside a context. This could be an especially useful refinement, as linking to math-rich fragments is often appropriate when discussing scientific materials. If there is interest, we can open a mirror issue in the WICG/scroll-to-text-fragment repository. I have checked all repositories for related issues - as far as I am aware this question has not been discussed before.

DG: So what it does is for parts of a document where you do not have id attributes, and you have no way to link into, because there's no Id attribute, you can add a little text directive, either with a continuous text snippet, or actually by adding using a range from to. So, text to match at the beginning, and a text to match at the end, or just an exact verb in text string to match. And it has an algorithm where it would preprocess the documents down to a string form, taking only the text notes and separating them by something they refer to as blocks, so things that are in line would come together. And whenever you switch block context, you would break and have a next entry.

This is important when you have a continuous long phrase, and the long phrase must be in the same paragraph. If you end the paragraph with a piece of a phrase and start the next one with the second piece that is no longer a continuous match, you must have a range "from to" to match.

DG is fond of example three in this issue in the first comment.

NS: Are there wild cards? DG No.

DG: Every element is a block in MathML. It is difficult to search using 'from to'. Several elements should be an inline.

DG: My hope for this issue is to motivate people so that they should treat MathML elements as inline.

NS: Safari supports most of it now.

DG: For math, we now have 2 new CSS display properties, "inline math and display math".

From Deyan Ginev to everyone: https://wicg.github.io/scroll-to-text-fragment/#has-block-level-display

BK: If there is a bug it is not in MathML but in the browsers.

ACTION DG: This is an opportunity to provide guidance on how MathML should be handled by this algorithm.

BK: First make a test to see if you know how the algorithm works. If there is a bug, if so, open an issue on their repro.

BK: David Bokan is one of their group members.

We are discussing the "scroll to text fragment" group. "https://github.com/wicg/scroll-to-text-fragment/issues/".

BK: The WICG "web incubator community group" is for groups that have some support (at least one vendor) but their issue is not big enough for a community group. Then, you can form a subgroup within the WICG. The "scroll to text fragment" group is such a sub-group.

  *   Define that (and how) glyph assemblies are mirrored in rtl formulas #235<https://github.com/w3c/mathml-core/issues/235>

In this issue, BB writes: (This is part of the I18n WG review.) B.4 Unicode-based Glyph Assemblies https://www.w3.org/TR/mathml-core/#unicode-based-glyph-assemblies

Maybe this section should say explicitly that the glyph assemblies are mirrored in right-to-left formulas. Firefox and Safari mirror them already, Chromium does not (but maybe that's an implementation bug). Unicode defines for some symbols what their mirrored versions are, but it does not do so for these 'extension' characters. So maybe the MathML Core spec itself should list the mirrored glyphs. It could add them as an extra column in the table. (The Unicode Technical Committee is still looking into whether to define some of these extension symbols as mirrored in a future version of Unicode, based on a larger proposal from 2022 'Glyph mirroring: ExtraMirroring.txt'<https://www.unicode.org/L2/L2022/22026r-non-bidi-mirroring.pdf>

BK: When we wanted to put some parameters in Chrome, and in level one, we decided to punt on certain hard problems, and to put these issues off into level two.

BK: How many of these hard problems do we have to solve to advance?

BK: This is part of the I18 review.

BK: Certain items like rspace and lspace have confusing names.

BK: We also have accessibility issues that need a response.

BK: I guess Firefox and safari handle issue 235 already, but Chrome does not.

NS: If it is a hard problem, send it to level 2, or say it is in the spec and is not implemented.

BK: Fred referred us to "rtlm" OpenType feature for RTL mirroring: issue 67<https://github.com/w3c/mathml-core/issues/67> which was discarded from mathematical core level one in the initial program release.

BK will reach out to BB to find out how do we handle the difficult cases for which we do not have answers. We have punted on things we cannot tackle now but are part of the review.

NS: There are two ways to handle this. One is to say this is a hard implementation problem and we will consider it in level two. The second way to handle things is to say it is in the spec, but it is not implemented.

BK: The response might be that the issue is working in two or three browsers.

BK: The question is "What do we spec"?

DG: I have a comment which may be useful for your discussion with Bert, which is that issue 67, from 2019, is still pertinent. Its last sentence is "I think we need more experiments / tests for these.", and that could be a viable reason to postpone specifying it, that we are not yet sure on specifics.

RESOLUTION/ACTION BK will talk to BB to see what we are required to do for the I18 review because we are not ready to handle some of these challenges.

BK: If you require the review you must pay attention to the issues.

BK: We can advance if not all hard things have been solved.

BK: Is someone willing to take up the work? We need tests and spec modifications.

BK: If you find something you want to talk about, tag it with "agenda".