> For the latter, I can only say that anyone advocating using MathML today despite its problems (poor layout and browser support) clearly cares about something else more than they do about actually communicating mathematics to humans.
Much of the reason people are in favour of providing MathML output is that if nobody did, then the likelihood of Chrome getting MathML support would have been near zero (and the risk of Firefox removing its existing (if imperfect) implementation, high). (A chicken and egg problem.) Since MathML is likely (you may disagree — but you must agree that it's plausible that if a JavaScript solution can do it, a native one can probably do it better) to lead to better equation typesetting on the web, once it's properly implemented, people advocating MathML today can very much care about better communicating maths to humans, in the long run. Also, MathML is not incompatible with MathJax — in fact, since MathJax's internal representation of equations is similar to MathML's, converting from MathML (to SVG/HTML+CSS/whatever) is faster than converting from TeX — so it's not as if providing MathML in the document dooms your readers you to its "ugly" output. (And yes, MathML can be both an input and an output for MathJax...)
> [...] (which for some reason is given on the page in low-resolution images rather than high-dpi images or SVG) [...]
That's because the page was made several years ago, when such images were the norm (look at a Wikipedia page on the Archive from even 2016), and hasn't seen significant updates since, because MathML was feared dead (due to Chrome, at the time, explicitly rejecting support) and volunteer effort dried up. Somebody™ should update this...
> Looking at the MathML sample page in Firefox [...], there are many that are worse and none that is better that TeX's output
For the little that it's worth, IMO five are worse, two are slightly better and the rest just as good as the TeX.
> And personally I've seen very little by Firefox/MathML people on their layout decisions (if they decided to do things differently from TeX, why?), while with MathJax I've seen that if their output is found not to match TeX's it is treated as a bug report and a fix attempted.
Far more people work on MathJax than on MathML — MathJax has a two-member team, plus support from AMS, plus volunteers, while MathML has only had occasional volunteers (see above; not that it was much better previously), so it's not a fair comparison. Also the page comparing TeX with MathML was made by the people in favour of MathML precisely because they care about trying to achieve parity with TeX.
> What are the some respects in which you say Firefox's output is visually superior to MathJax's?
For instance the speed with which the output is rendered. Several second latency for better final appearance might be a bargain you want to take, but it's still a visual trade-off. (You can use server-side MathJax, but then you lose some end-user customisability.)
> the tag soup of MathML, though shorter, has still all the XML ugliness so it's not as if it will ever be readable.
How else would you expose the structure of an equation, to the DOM, than with XML ugliness? It's just important that the XML ugliness makes sense (and MathML's does).
Much of the reason people are in favour of providing MathML output is that if nobody did, then the likelihood of Chrome getting MathML support would have been near zero (and the risk of Firefox removing its existing (if imperfect) implementation, high). (A chicken and egg problem.) Since MathML is likely (you may disagree — but you must agree that it's plausible that if a JavaScript solution can do it, a native one can probably do it better) to lead to better equation typesetting on the web, once it's properly implemented, people advocating MathML today can very much care about better communicating maths to humans, in the long run. Also, MathML is not incompatible with MathJax — in fact, since MathJax's internal representation of equations is similar to MathML's, converting from MathML (to SVG/HTML+CSS/whatever) is faster than converting from TeX — so it's not as if providing MathML in the document dooms your readers you to its "ugly" output. (And yes, MathML can be both an input and an output for MathJax...)
> [...] (which for some reason is given on the page in low-resolution images rather than high-dpi images or SVG) [...]
That's because the page was made several years ago, when such images were the norm (look at a Wikipedia page on the Archive from even 2016), and hasn't seen significant updates since, because MathML was feared dead (due to Chrome, at the time, explicitly rejecting support) and volunteer effort dried up. Somebody™ should update this...
> Looking at the MathML sample page in Firefox [...], there are many that are worse and none that is better that TeX's output
For the little that it's worth, IMO five are worse, two are slightly better and the rest just as good as the TeX.
> And personally I've seen very little by Firefox/MathML people on their layout decisions (if they decided to do things differently from TeX, why?), while with MathJax I've seen that if their output is found not to match TeX's it is treated as a bug report and a fix attempted.
Far more people work on MathJax than on MathML — MathJax has a two-member team, plus support from AMS, plus volunteers, while MathML has only had occasional volunteers (see above; not that it was much better previously), so it's not a fair comparison. Also the page comparing TeX with MathML was made by the people in favour of MathML precisely because they care about trying to achieve parity with TeX.
> What are the some respects in which you say Firefox's output is visually superior to MathJax's?
For instance the speed with which the output is rendered. Several second latency for better final appearance might be a bargain you want to take, but it's still a visual trade-off. (You can use server-side MathJax, but then you lose some end-user customisability.)
> the tag soup of MathML, though shorter, has still all the XML ugliness so it's not as if it will ever be readable.
How else would you expose the structure of an equation, to the DOM, than with XML ugliness? It's just important that the XML ugliness makes sense (and MathML's does).