In MathJax rendering it looks good to me

@SalixAlba would you agree?

From what I see:

<mfrac>
	<mrow data-mjx-texclass="ORD">
		<mi>a</mi>
	</mrow>
	<mrow data-mjx-texclass="ORD">
		<mrow data-mjx-texclass="ORD">
			<mi>b</mi>
			<mo>/</mo>
			<mn>2</mn>
		</mrow>
	</mrow>
</mfrac>

I don't see space manipulations in the MathML output.

As a reference also the LaTeXML rendering looks similar

<mfrac>
	<mi>a</mi>
	<mrow>
		<mi>b</mi>
		<mo>/</mo>
		<mn>2</mn>
	</mrow>
</mfrac>

looks identical.

As the rendering is equally large among browsers, it is either the expected behavior or an issue with the MathML spec itself. What is your feeling @SalixAlba

In Firefox you can use

<math xmlns="http://www.w3.org/1998/Math/MathML">
  <mi>a</mi>
  <mo>+</mo>
  <mi>b</mi>
  <mpadded width="0.1em" lspace="-0.15em"> 
    <mo>/</mo>
  </mpadded>
  <mi>c</mi>
</math>

Which renders as

But, negative lspace is not part of MathML core, and is not supported by Chrome. Which renders as

Clearly not great.

The problem seems to be in the Operator directory (https://w3c.github.io/mathml/#oper-dict)
where / solidus has an lspace of 4 and rspace of 4.

We can override these attribute for individual operators

<math xmlns="http://www.w3.org/1998/Math/MathML">
<mi>a</mi><mo>+</mo><mi>b</mi>
<mo lspace="0" rspace="0">/</mo></mpadded><mi>c</mi>
</math>

Renders as

In Chrome and Firefox. Which looks acceptable.

Whether we should is another question.

I really don't know. Maybe it is not desired that + and /have different spacing. If you want we could ask the w3c math WG?

I'm inclined to think that we want to be closer to LaTeX conventions than MathML ones, so lspace="0" and rspace="0" is appropriate.

There is a related question about the | operator, used in conditional probability <math>p(a|b)</math>
and rendered with lots of space.

{F57566599}

SVG is tighter

{F57566610}

MathML has different default space when its a prefix op (lspace=rspace=0) and an infix op (lspace=rspace=5).

This seems to give inconsistent spacing, when used as bra-kets so <math>|b\rangle</math> has no space but <math>\langle a | b \rangle</math> has more space.

In T375337#10185786, @SalixAlba wrote:

There is a related question about the | operator, used in conditional probability <math>p(a|b)</math>
and rendered with lots of space.

{F57566599}

SVG is tighter

{F57566610}

MathML has different default space when its a prefix op (lspace=rspace=0) and an infix op (lspace=rspace=5).

This seems to give inconsistent spacing, when used as bra-kets so <math>|b\rangle</math> has no space but <math>\langle a | b \rangle</math> has more space.

Unfortunately, I can not see the pictures. It seems they are access-restricted.

In T375337#10185784, @SalixAlba wrote:

I'm inclined to think that we want to be closer to LaTeX conventions than MathML ones, so lspace="0" and rspace="0" is appropriate.

I think it would be good to check what others (e.g. arxiv) do here.

I submitted a request to the MathML WG.

@Physikerwelt What happens if, after we roll this out, one of the browsers picks up the change in spec. Does that conflict in any way? If not, I suppose if could go ahead with our overwrite in the mean time.

There is quite a long lee way for browser adoption in practice. It seems likely to be at least 12 months before all three implement it. Then, another 4-6 months for their release cycle to end. Then the browser release adoption rate which in the case of Mobile Safari is ~4 months to get 90% of the peak of a single version's usage of Mobile Safari. With all that in place we'd still only be at 70-80% in terms of actual traffic. If you want to reach 90% it'd optimistically be 3 years away as more of the long tail upgrades, including forks and repackaged versions (such as UC Web, ref T178356#8740573).

In T375337#10307085, @Krinkle wrote:

@Physikerwelt What happens if, after we roll this out, one of the browsers picks up the change in spec. Does that conflict in any way? If not, I suppose if could go ahead with our overwrite in the mean time.

No, it's not a problem. We would follow the suggestion of @SalixAlba

In T375337#10185784, @SalixAlba wrote:

I'm inclined to think that we want to be closer to LaTeX conventions than MathML ones, so lspace="0" and rspace="0" is appropriate.

with a custom CSS class. For browsers that would have already picked up the change, the CSS class would have no effect (despite a neglectable performance decrease).

I want to make sure that we don't reinvent the wheel. I would guess there are many instances where Wikimedians (here @SalixAlba) discover problems in standards, which are then fixed for everyone. Do we have a process for that?

Change #1089140 had a related patch set uploaded (by Physikerwelt; author: Physikerwelt):

[mediawiki/extensions/Math@master] Overwrite spacing for divide

https://gerrit.wikimedia.org/r/1089140

Change #1089140 merged by jenkins-bot:

[mediawiki/extensions/Math@master] Overwrite spacing for divide

https://gerrit.wikimedia.org/r/1089140

Change #1091836 had a related patch set uploaded (by Krinkle; author: Physikerwelt):

[mediawiki/extensions/Math@REL1_43] Overwrite spacing for divide

https://gerrit.wikimedia.org/r/1091836

Change #1091836 merged by jenkins-bot:

[mediawiki/extensions/Math@REL1_43] Overwrite spacing for divide

https://gerrit.wikimedia.org/r/1091836