MathML-Core Agenda: Nov 27, 2023

[bkardell]

• Ready to republish / request wide review... Check in with @bert-github
• Make ::first-letter and ::first-line pseudo-elements not applied to elements with display: math
• Specify empty treatment (re-revisted
• Vertical Alignment of delimiters
• Adjusted height & depth of elements moved via voffset
• munder, mover, munderover: needs clarity in spec and consistency in implementation

NS: Updated to add new issue 213

[bkardell]

11/27/2023 MathML Core Meeting

Attendees

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

Regrets

• Bert Bos

Agenda Items

Announcements/Updates

The Next MathML Core meeting will take place on Monday, January 29, 2024.

Issues

Ready to republish / request wide review... Check in with [@bert-github](https://github.com/bert-

github)
BB published a new working draft, and BB gave BK the information BK needed for the CR.
NS said that BK will have to reach out to the five horizontal groups.
BK: I needed to get an updated working draft published because there's other specs that want to link to
it.

[Make ::first-letter and ::first-line pseudo-elements not applied to elements with display:

math](#211)
BK: Fred said there are good reasons not to apply it in MathML. Fred made the changes.
BK: The resolution I'm proposing is that we affirm Fred's statement
to not respect first line first letter.
BK: Fred wrote several tests. Fred's second test is not correct.
BK: Fred thinks he agrees that the test is invalid.
DG: So, I agree completely with Brian's resolution.
NS: I agree because, in some sense, what should happen with a display value of math on any element
that's not in MathML is not defined.

BK: The proposed resolution is We accept Fred's spec text surrounding first line and first letter not
applying to elements who's computed display value is block math and inline math, and we believe that
test number 2 needs to be reversed.

Specify empty treatment (re-revisited

DG Wanted DC to be in on this discussion.
DG: There is a subtlety with the way operators are laid out which has to do with MRO. So, the place
where lspace and rspace are handled in the spec text is in the mrow text, not in the mo text.
NS: Yeah, so in some sense what the suggestion here is that normally you would consult an operator
dictionary and look up the operator and if it doesn't match then there's some default behavior which
adds an appropriate amount of lspace and rspace for an empty operator.
BK: The group believes that the spec needs improvement.
BK: Firefox and Safari look different in these cases.
DG: Chrome is incorrect and Firefox is correct.
BK: Do people think this is a problem and the spec should be fixed? Yes.
DG: Right but see this is the subtlety. I think David wants to have the text change. And to me, if you
change the operator dictionary to have an empty entry that has lspace and rspace 0, that is enough
without touching the spec for the issue I have concerned with, then Chrome will be fixed if you consult
that entry.
DG: Does not think he can make such an edit without more discussion.
NS: The line has to change because it is wrong.
ACTION NS will make a note about this.

Vertical Alignment of delimiters

BK: This was discussed at the August 28, 2023 core meeting.
NS wanted to add four words but Fred disagreed.
NS said that DC found a bug about this.
BK: Do we have any action for this?
BM: It may be nonsense, but it is too late to change it now.
NS: There is a work around without changing the spec.

BM: It is ugly and confusing, but BM is not sure that we can do anything about it now.
And not only is it ugly from an authoring point of view, but it's also kind of confusing in the spec what
the implementation should be doing.
NS: If you change it what else breaks?
DG: If Ron is happy, we can close the issue.
ACTION NS will leave a note about this.

[Adjusted height & depth of elements moved via voffset](https://github.com/w3c/mathml-

core/issues/203)
BK: There are a number of problems because implementations are not in sync.
BK: I think it would be a reasonable default to shift height and depth automatically because that is what
I think most people normally want.
BK: Is this a valid issue? Do we need to keep it open? It wasn't clear to me because I had first thought
that you were saying that this is not going to work right now until we get interop on these things.
BK: Perhaps we only need interoperability on CSS stuff.
NS: What will get broken if we change the default?
NS: If we change the spec, we will break things.
NS: It's kind of an ugly situation in core because to do the thing right, you are going to make a change in
MathML and then you're going to have to make a stylistic change in CSS.
NS: Does CSS have a way of basically changing the baseline of something? Can you make the desired
change totally in CSS? Can this vertical alignment make an incremental change?
BK will look at this more carefully.
NS: Do we make a note or close the issue.
DG: CSS may have practical solutions.
ACTION BK will write up the comment for this one.

Converting W3C documents from MathJax to MathML

BK: There are over 1,000 repos using MathJax where they could be using MathML. To get attention for
MathML, should we convert them to MathML?
BK: We need some success stories about people using MathML.

NS: There are still interop issues with MathML that MathJax does not have because MathJax has been
around for such a long time.
NS: Publishers may worry if they are hitting some of the interop MathML bugs.
BK: We need browsers to increase their investment in MathML.
Google search is starting to use math.
BK: We need to find some battles we can win.
NS: to DG: Are you using MathML core for your switchover with archive?
DG: yes. There should be an announcement before the end of the year.
DG: Our site is a testing site. We show bugs. There is some broken stuff.
BK: is seeing this in CSS related specs.
DG: suggested the W3C change the default rendering from MathJax to MathML.
BK: We should work with the standards community to bring up MathML.
BK: will start doing work to increase the use of MathML.
He has a book "the effects of nuclear weapons", which uses MathJax. He Plans to convert it and
document the good effects of MathML.
BK: is looking for help in getting more documents translated.
BK: We need to make progress.
BM: People are used to working around MathJax bugs and not MathML bugs.
BK: Does anyone have reservations about changing documents?
NS: can produce MathML.
NS: Machines write html.
NS: Is offering to help transform MathJax into MathML.
BK: Does anyone want to write social media posts about converting files to MathML?

[munder, mover, munderover: needs clarity in spec and consistency in

implementation](#213)

---