Should we drop HTML rendering?

[flying-sheep]

Now that all major browsers support MathML again (in the form of MathML Core), HTML rendering doesn’t really have much of a purpose anymore. Not setting output: 'mathml' in modern browsers basically just means: I want to burn CPU cycles for nothing.

Follow-up question: Should KaTeX merge with Temml again?

[edemaine]

I didn't think the quality of MathML rendering was on par with HTML rendering (partly because MathML just isn't as expressive, perhaps by design). I'd be happy to be proved wrong but I think it needs proof...

[flying-sheep]

what do you mean? It can be styled with CSS just like HTML, right?

[edemaine]

I mean that the HTML output from KaTeX rendered by a web browser looks closer to what LaTeX would render, compared to the MathML output of e.g. Temml rendered by a web browser.

[flying-sheep]

Wouldn’t it be easier to tweak this towards what is desired than to build the layouting using HTML+CSS from the ground up?

And even if the perfect MathML+CSS solution needs similar amounts of CSS for comparable results to the HTML+CSS solution: KaTeX’ resulting code complexity would be much easier to handle as there’s only one renderer.

[ronkok]

If you are looking for a MathML-only library, I've written one at Temml.org. Temml is a fork of KaTeX and my hope is that it will get wide use someday, not yet today. I think that MathML will eventually be rendered really well by all three of the major browser engines, but they are not quite there yet.

• Firefox is quite good. I've been able to work around the few issues with CSS adjustments.
• Chromium is fair. If you use the Latin Modern font, there are only a couple of issues. But if you use a system font, extensible arrows fall apart and you get some very odd parentheses from \bigg( and \Bigg(.
• Safari (Webkit) has major issues with accents, \overbrace, boxes, \mathllap, and extensible arrows.

If you want to judge for yourself, you can take a look at the Temml function support page and try it with various math fonts.

[flying-sheep]

A bit of a chicken-egg problem. If people use KaTeX or MathJax and those render to HTML, there’s no huge incentive to invest into MathML rendering. I was hoping to get a conversation going if KaTeX and Temml will be able to un-fork and if yes, then what’s blocking it.

[ronkok]

I think the hurdles that discourage MathML are now mostly the browser rendering issues. To help along those lines, go to the bug reporting bulletin boards and star the issues you think are most important. Even better, contribute some money so Igalia can continue their work improving MathML rendering.

[ronkok]

Follow-up question: Should KaTeX merge with Temml again?

Sorry. I did not notice that you already referred to Temml. My take is in two parts. (1) No merge can be even thought of until MathML gets top-notch rendering in all three major browser engines.

(2) After that, I personally think a merge would be cool, but there will likely be opposition. LaTeX purists are likely to disagree because MathML will never render exactly like LaTeX. There may also be opposition to some things I did with the code. For instance, I threw away all type annotations. I also abandoned some Khan Academy linting rules. Taken all together, I think a merge would be unlikely to get a consensus agreement.

[flying-sheep]

For instance, I threw away all type annotations.

Oh. What is the rationale for that decision? I find myself quite discouraged from considering to contribute when discovering that a JS library hasn’t yet been converted to TypeScript. Removing typing is an action that I considered to go so much against maintainability that I didn’t even consider anyone might possibly take it!

I didn‘t even think that Temml might not have typing. “it’s new enough and well tested enough that clearly the maintainer cares about maintainability, so it’s going to be written in TypeScript”, was probably my thinking process.

[ronkok]

As you have noted, the chicken-and-egg aspect discourages effort in MathML. I expected Temml would either have to be something I did entirely by myself, or it would not happen at all. Since I was looking ahead at quite a lot of work, I decided to get comfortable and do things my way.

Typing certainly has value, but I question if the amount of value is equal to the effort involved for this particular library. I've contributed many bug fixes to KaTeX, but I cannot think of a single one that would have been prevented by static typing. And solo projects in general derive less value from typing.

hasn’t yet been converted to TypeScript.

Then you have more problems. KaTeX is not a TypeScript library. It is a Flow library. There is an open pull request to convert to TypeScript, but it needs an enormous amount of work and it has been dormant for 2 1/2 years. Apparently, there are other people who also think that typing has value, but not enough value to justify their own time.

[flying-sheep]

And solo projects in general derive less value from typing.

I’ve not made this experience, but this is yours, fair enough.

There is an open #2326 to convert to TypeScript, but it needs an enormous amount of work and it has been dormant for 2 1/2 years.

Yeah, things like this have to be done progressively, and with ample support by the maintainers. Basically: Someone needs to start converting individual files/areas and have someone fast-track the resulting PRs. Once all is said and done, the gains by typing can really be felt, as contributors can just code with assistance by the type system instead of having to look up what object shape one API or another expects.