MathML-Core Agenda - Monday, April 29, 2024

[bkardell]

Add more details to the stretchy algorithm

Define Accessibility Mappings for MathML Elements
#196

i18n review
- Define that (and how) glyph assemblies are mirrored in rtl formulas

• Explain the mapping tables (appendix C)
• Whether/when to mirror operators #233
• lspace/rspace have confusing names #232
• Clarify single character of mi as italic #231

APA review

[polx]

Could we discuss MathML Elements in the HTML Sanitizer?

[fred-wang]

https://lists.w3.org/Archives/Public/www-math/2024May/0013.html

[bkardell]

Minutes

03/25/2024 MathML Core Meeting

Attendees

• Brian Kardell
• Neil Soiffer
• Louis Maher
• David Carlisle
• Deyan Ginev
• Bruce Miller
• Bert Bos

Regrets

Agenda Items

Announcements/Updates

I think we are all set for wide review stuff..?

BK: has filed the request for a horizontal review.

NS: I am nominally on the accessibility platform architecture (APA) group.
I should look to see if the request was filed. It was.

Fred has updates on the issues we will consider today.

Fred got a lot of tests from Mozilla exported and synchronized with WPT https://groups.google.com/a/mozilla.org/g/dev-platform/c/qGqxddNMkOQ/m/30j9eblcAwAJ / https://github.com/web-platform-tests/wpt/commits/master/mathml

Issues for publishing CR draft

BK to BB: We requested a horizontal review and gave the end of April as a date when we will request a CR. Can we check this box in issue 170 now, or do we have to wait until the end of April?

BB was unsure.

BK Do we publish the CR drafts before or after the end of April?

BB: Do not publish before the end of April.

BB: You can publish the editor's draft on GitHub. Check the 170 checkbox at the end of April, then I will submit the CR request.

NS found the MathML review entry in the APA issues tracker. No one has looked at it yet.

Idea: Consider introducing CSS math-leading-space / math-trailing-space properties #218

BK: Fred said this is an idea aligned with the goal of exposing magic via CSS. Fred thinks that will help address some of the user customization issues that we have with hard coded operator dictionaries right now and would facilitate maintenance. Fred is not sure this is a high priority issue now.

BK: Asked for questions.

NS: Fred wants to allow someone to put the operator specification as a CSS rather than as an attribute value.

DG: DC and I liked the idea a lot.

DG: The only discussion I had in mind is that there is this padding left padding and right, and this is in spirit with padding left and padding right. But it is for math operators, so it acts a little different than the one on the boxes. The name is extremely far removed from padding.
Lspace and rspace, the left and right. If you had LTR, these terms could flip.

BK: I would expect both to flip.

BM: We took the approach that left the "L" was leading, and the "R" was trailing. So that interpretation should be embedded in the full spec.

DG: Wonderful.

NS: Why are these different names than what MathML was using before?

BK: That would be a fine thing to add to the issue.

BK: Everyone should look at it and take it offline and discuss it. It is not the highest priority, but everyone agrees that it would be useful.

BK: Should this have a future label on it? Does it have a level 2 label?

BM: Does this require help from CSS?

BK wants to start a discussion on this.

l### Alignment of delimiters

BK: Fred suggested that he expects the spec might not need to be updated and that it is just a bug in chromium, but not firm.

DG: The resolution was not to make changes.

DG: There are several things that break. It is hard to know why. It could be a spec or bug. Needs to find a test showing the problem.

DG: I need to read more of Fred's existing tests.

ACTION DG will find a test he wants to discuss or make one.

NS: We can close this issue if a chrome bug report has been filed.

ACTION BK to identify whether there is a chromium bug for vertical alignment. If there is, close 205, adding a link to the chrome bug.

Define Accessibility Mappings for MathML Elements

BK: This should be closed. Here is why I held off just closing it [explains some history].

BK: Joanie, from Igalia and who was an aria co-chair, had spun up an AAM copy that was just for MathML, has stepped down since and is focusing on implementation things these days. Val Young, also from Igalia, is a new co-chair and I talked to her about what to do with this. She also cannot just take it on and does not know MathML. So, we needed a co-author. I spoke to Neil and he has agreed to be co-author on that spec. (MathML-core AAM). I would like to close this issue. It does not belong to MathML core; it has its own repository. I have held off though because Neil has not been named co-author yet, nor Val (not sure if that one matters as much)... We were going to send a pull request for Neil to get added to the AAM?

NS: I can add the request to add myself to the AAM.

ACTION NS will submit a request for ns to be an editor of the MathML AAM (Accessibility API Mapping). NS will close 196.

Regenerate PNG examples with official chromium build #155

BK: Can we just close this?

BK: Fred's feedback is that the last time he tried there were some issues due to some rendering bug in chrome. There were issues with operator stretching due to layout limitations.

DC: Close it and reopen it in the future if necessary.

ACTION Close 155. There is no action required. This decision was made at the Math WG Core meeting of 3/25/2024.

Applying visual effects

BK: Question: do we need to do anything? Fred believed that these things were fixed. BK will meet with Fred separately.

RESOLUTION BK: As resolved today in the meeting: We believe the issues referred to in the OP (containing block and stacking context discussion) were fixed and that many tests have been added since. These visual effects should now just work, but if @chrishtr feels that we still need additional tests, please feel free to reopen. Close 162.

percentage of minsize/maxsize

DG: We want to align MathML 4 and the core.

BM: We either change the full spec to match the core spec, then Firefox must be patched; or we revert core back to what full always said, and then chrome will need to be patched.

FW: I would need to check this one. I do not have a strong preference as a user. But as an implementer, just want to make sure we are not introducing something that violates browser's layout model or complicates the implementation needlessly (that might be the reason of the change, but cannot remember)? At glance, it seems quite easy to get calculate a percent of the target size while during layout for the other option we would have to calculate a percent of the unstretch size of a core operator (which can be deep in the tree due to embellished op and so on). It would be worth giving a try with Chromium.

NS: We need to be governed by what is implementable. It is possible that Fred made the same mistake that David and I made about thinking it was referencing the stretched size, or not.

BM: It could be the CSS convention that causes the confusion.

DG: In CSS, max height refers to the parent.

NS: How much will break if we change the spec?

BM: In DLMF, specific sizes are not used much but growable sizes look better IMHO.

DG: ar5iv 2024 stats:
mo: 4,704,693,527
mo@maxsize: 69,820,857

From Brian Kardell to Everyone: HTTPArchive/almanac.httparchive.org#3619 ... actually, maybe disregard, that wouldn't be good as a data source because it is biased away from stuff with math to begin with even.

BK: If you have further thoughts, share them on the issue; and let Fred know how important this is.

Sanitizer API](#227)

This should go onto next month's agenda.