In T353000#9391383, @ovasileva wrote:

@ovasileva to check on timeline

Thanks for queueing that work! Q3 works fine for us in terms of timeline but we're flexible. The main goal for this work IMO is to understand if we need to keep mathoid for WMF projects and make a plan to support it outside of restbase.

That being said, the sooner we know it the better but this is an expected long-tail type of work so you can prioritise according to your roadmap. Please let me know what works best for you.

I noticed https://www.reddit.com/r/wikipedia/comments/1auuall/mathematical_notations_stop_working_when_i_log_in/?share_id=VoPF5VfNZzjrs5VxEqNoI&utm_content=1&utm_medium=android_app&utm_name=androidcss&utm_source=share&utm_term=10 on reddit - is this the sort of thing we should be on the look out for during QA @Physikerwelt ?

I was able to replicate this on
https://en.wikipedia.org/wiki/Spin_quantum_number#Electron_spin
when I set preference to LaTeX source:

In T353000#9568787, @Jdlrobson wrote:

but I assume that's expected behaviour? That said,t hose preferences are pretty confusing - one of those should have "Recommended" or the preference itself should be marked as "Advanced" - for laypeople I don't think they'll know the difference between LaTeX and MathML)

git blame tells us that the description was changed 9 years ago by @thiemowmde https://github.com/wikimedia/mediawiki-extensions-Math/commit/5563cda43d67ef3838d25def26bfc518929b6a95 10 years ago we felt that leave it as tex https://github.com/wikimedia/mediawiki-extensions-Math/commit/c61b8becac714ca4d6c694f48c736fb5753a8977#diff-1a490f08504158838befaa816ee8d5c08dff9e694d5a568ce4b0a4398dcc563eL10 would be too verbose. But the origin of recommendation for text browsers is like much older as even 10 years ago text browsers (such as w3m) were not that popular. This points out that it is very valuable to have someone looking onto the functionalities with a fresh pair of eyes. I guess this can even be changed without touching the extension code on translatewiki. So please go ahead and change it:-)

Also note that native rendering is not enabled on all wikis and I was planned to wait with enabling it everywhere https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1002639 until this review is done.

Side comment: The popups for math don't work in "text browsers":

I was really bad at writing commit messages back then. I'm sorry for that. As far as I remember my motivation was that users tend to confuse "TeX" for a misspelled "text". While "TeX" might be technically more correct in certain contexts it's less confusing for not so technical users to consistently use "LaTeX".

But this seems to be mostly unrelated to this ticket, or is it?

@thiemowmde I created T358523 for that issue. It is unrelated, just something that came out of QA :)

Thinking about text browsers, I just realized that using MathML inline should be a huge improvement for screen readers. Do we know how well they support MathML? I just skimmed https://w3c.github.io/mathml-docs/gap-analysis/

In T353000#9579649, @daniel wrote:

Thinking about text browsers, I just realized that using MathML inline should be a huge improvement for screen readers. Do we know how well they support MathML? I just skimmed https://w3c.github.io/mathml-docs/gap-analysis/

Yes. We also have an experimental flag for the proposed intents, which can be used to overwrite heuristics. Check out https://nsoiffer.github.io/MathCATDemo/ for an interactive demo. I think even without manual intent overwrites, the outcome is quite good in most cases.

First pass familiarizing myself with this landscape, there is definitely a visual difference between the mathoid(?) image and the MathML native rendering, at least on my MacBook. I'm guessing this is known, but wanted to spell it out explicitly. Am I correct in understanding the main goal of this ticket is ensuring the two different rendering methods are comparable and that MathML can be shipped without causing regressions in user experience?

Gonna keep documenting findings in the ticket for now, unless someone objects. The \left\vert s \right\vert and \lVert z \rVert look a little squished. In general, spacing in MathML is noticeably tighter, especially for the trig functions

On a positive note, night mode works out of the box with MathML, whereas the images are unreadable against a dark background

There is quite a big difference between images and MathML. However, also Mathoid did produce MathML before. How it can be activated is described here https://www.mediawiki.org/wiki/Extension:Math#Viewing_math . It the mathoid MathML looks better than the new rendering option it is clear regression. Another rendering option that tries to mimic TeX rendering or the old images, is currently waiting for security review. My suggestions would be to list the regressions, such as the spacing issues, as the letters s and z in \left\vert s \right\vert and \lVert z \rVert should really be centered. For me it would be most convenient to have individual subtasks.

@Physikerwelt ah perfect, thanks for the quick response! I'll try comparing the mathoid MathML to make sure it's identical, then continue noting any visual issues such as the spacing. From there, we can create subtasks to address them while I figure out how to add the math regression tests to pixel (our visual regression suite)

Spacing looks a lot better on firefox, so I think part of the issue is that I was using chrome before. Also got the MathML mathoid output working on firefox after a lot of trial and error, comparing them now

Weird spacing with operatorname (opposite problem in mathoid mathml where it's very wide)

In T353000#9582185, @SToyofuku-WMF wrote:

Weird spacing with operatorname (opposite problem in mathoid mathml where it's very wide)

It could potentially be a sign error. Which one is correct depends on the user input TeX... Either she wants a negative or a positive space.

Question for @Physikerwelt and @MSantos: after we finish QA, is the plan for this to immediately be the default, or will it be added as an additional option, with the removal of mathoid at a later date? I'm working on getting set up with a browserstack account for further testing and adding the visual regression tests I mentioned, but curious to know exactly how rigorous we should be here

@SToyofuku-WMF, the more rigorous you are, the better. It's better to know all the bugs now.

The next step is to enable the rendering as an opt-in for all languages T358803.

Accents and diacritics a little funky on safari

Accent/diacritic issues and operatorname spacing on iphone

For the pixel tests (commenting here since my pixel instance is broken):

• it looks like copying from https://en.wikipedia.beta.wmflabs.org/wiki/Help:MathTestNative will get us a lot here, especially since it seems to provide a forcemathmode option which would be perfect for pixel
• in particular I'd copy the first four sections, since that's where most of the issues I noticed showed up, and then at least one of the more complex sections from lower down the page (either integrals or the large composite fractions seem like good contenders)
• I think with forcemathmode it should work without any user configuration, so ideally we shouldn't have to do anything crazy with the user prefs

Thanks @SToyofuku-WMF I can take over the Pixel part of this tomorrow as discussed.

In T353000#9589182, @SToyofuku-WMF wrote:

Accent/diacritic issues and operatorname spacing on iPhone

Thank you.

What is the process regarding this issue? IUnderstandingif this looks better with mathoid MathML rendering. It would be good if the mathoid MathML rendering could fix the problems (relatively quickly) by adjusting the math extension source code so that the generated HTML output is more similar to the HTML generated with MathML rendering. If both versions are problematic, it gets more complicated.

In T353000#9588772, @Physikerwelt wrote:

The next step is to enable the rendering as an opt-in for all languages T358803.

Do you see any argument against proceeding with this step? I checked my calendar, and the afternoon of March 5th would be a good date for enabling this as an opt-in everywhere. I would be happy to get any feedback on this.

@Physikerwelt Steph our developer has taken a pass. We'll now move this to our test engineer Edward. When that's done we'll move this to the sign off column and our board and @ovasileva will be able to give you an answer to that question.

Wow, you have a really elaborate workflow. I'm impressed. I can not access the second file

In T353000#9602162, @Physikerwelt wrote:

Wow, you have a really elaborate workflow. I'm impressed. I can not access the second file

.

@Physikerwelt I fixed the second file. You should be able to see it now.

Yes. Thank you

@daniel @ovasileva I looked at https://phabricator.wikimedia.org/project/view/6289/, and it seems there is quite some work to do for restbase sunsetting. If we want to disable/deprecate the current default rendering mode, which relies on mathoid via restBASE before release 1.42, we should enable it as an option very soon.

I am now waiting for this issue to be closed before proceeding with T358803 as suggested by @Jdlrobson

@ovasileva over to you to give @Physikerwelt the green light. Pixel now has a UI regression test for Math equations so we can monitor these going forward.

Thank you. I am confident that we can resolve the remaining issues quickly. The challenge is to collect samples in the form.

For the input ..., the HTML output is ... but should be ... . If we have those samples, most issues can be fixed within a few minutes.

However, I have difficulties processing feedback like does not look good.