Hacker News Reader

Comment by MontyCarloHall | Hacker News Reader

This is amazing. Probably the final nail in the coffin of MathML; what’s the point of a non-human readable intermediary language that other higher-level languages get compiled to, that only works in certain browsers (and with browser-dependent rendering/implementation), when you can instead write directly in LaTeX and have KaTeX work identically everywhere?

View on HN

MathML support in Chrome has been greatly enhanced just in January [1].

I don't have strong opinions, but I guess the advantage over TeX is, as always, that MathML is much better integrated with the web stack and markup such that you can target math formulas using CSS, that it has much better accessibility, internationalization, and search, that you can use JS/DOM access with MathML for educational and science presentation apps, etc.

It's not like TeX is uncontroversially better (eg Turing completeness, terse, lacking editor support, print-oriented, purely presentational, ...)

[1]: https://mathml.igalia.com/news/2023/01/10/mathml-in-chromium...

Edit: arguably MathML is excessive as well but at least its XMLism such as insistence on enclosing every operand in tags as the primary source of bloat and incomprehensibility in presentational math can be somewhat mitigated using SGML, as was already suggested with MathML's precursor in 1995 or so [2] for high school math and/or custom math fragments.

[2]: https://www.w3.org/MarkUp/html3/maths.html

I don't understand MathML's intent; likely because I have a different design mentality or model.

I like to represent things like this in 3 forms:

#1: Rendered notation for reading; what all these tools produce for people reading the document

#2: A clean, well-documented API for writing. This is the Latex, Mathjax, katex syntax etc, replete with backslashes.

#3: A representation in a computing language used to create the rendered form from the API. Depends on the language, but ie something like a set of structs and enums that can be manipulated by a compiler.

MathML is none of these; it's neither readable, nor writable, nor manipulable natively by a programming language.

Think of MathML like SVG. It is a target language which browsers understand. With SVG you can write it in hand, but most likely you are gonna use a special editor (Inkscape) or a library (d3).

With MathML you can write your equations e.g. in libreOffice or pick a library like MathJax or TeXZilla.

In fact I wrote a library my self which compiles a AsciiMath derived language to MathML, it was my first time writing a compiler, and it was an absolute joy targeting MathML. The mapping between DOM nodes and XML nodes is a perfect fit for the web as it allows my to implement DOM as a direct target (`mathup(expression).toString()` vs. `mathup(expression).toDOM()` and even `mathup(expression).updateDOM(parentNode)`.

The documentation for MathML on MDN if fine actually, good enough for me to write a compiler. The structure of the language is much easier to compile to than LaTeX by nature of actually having a standard (as opposed to an implementation which functions as a standard).

MathML is a unique fit for what it was intended to do, which is a targeting language which browsers understand.

MathML is not just for presentation. It encodes a lot of semantic information that Latex leaves out, and that information can be useful for accessibility, computer algebra system interoperability, etc. That said, I don't think it's used much for those things. I had really high hopes for MathML when it was first announced, but the poor browser support and consequential lack of use has been really disappointing.

Marking up the semantic structure of all your mathematical formulas is about as likely as marking up the parse tree and parts of speech for all your regular prose sentences. Presentational MathML is the only thing that matters; Semantic MathML is W3C semantic web wank.

The idea is the MathML is generated by a computer algebra system or similar which has all that data, not manually.

What if you do not have any computer algebra system in your pipeline? LaTeX can be written and read by actual humans, MathML cannot.

You can use latex to author mathml, like we everywhere use markdown to author HTML.

The first hit in Google for "latex mathml converter" is https://temml.org/ . The list of supported LaTeX constructs looks fine, but the output… The example LaTeX converts to 67 lines of MathML. The vectors (arrows above B, l, E) are built like this:

    <mover>
      <mi>B</mi>
      <mo stretchy="false" style="transform:scale(0.75) translate(10%, 30%);">→</mo>
    </mover>

But the hat above n is:

    <mover>
      <mi>n</mi>
      <mo stretchy="false" style="math-style:normal;math-depth:0;">^</mo>
    </mover>

Markdown is great, but I can always take the HTML produced by a Markdown→HTML converter and edit it by hand, since HTML is human-readable and human-editable. MathML is neither.

The output of MathML is also uglier than KaTeX’s, with wonky spacing. In Firefox, there’s an ugly space after all \d's (derivative sign). It’s better in Edgium, but there is still an ugly space in \d\vec{l}.

If I need an intermediary tooling/format for math, I’d prefer beautiful LaTeX-esque output, and keep LaTeX code that wold be converted by KaTeX on the fly to whatever ugly HTML is required.

Is that the canonical mathml way of expressing vectors? Then yikes, I thought it's more semantic than that

LaTeX is isn't semantic, so how could MathML computed from LaTEX be semantic?

\vec{x} is quite semantic.

I guess <mover> is semantic enough, actually? Though I don't get why the engine doesn't just know to render the arrow appropriately and it needs all those <mo stretchy> things with inline styling.

<mover> has a boolean accent attribute so I guess you can write:

    <mover accent="true">
      <mi>B</mi>
      <mo>→</mo>
    </mover>

So maybe that's a problem with a particular latex->mathml convertor, but the idea itself should work.

What is anyone going to do with that information?

> as likely as marking up the parse tree and parts of speech for all your regular prose sentences

That sounds completely doable with modern NLP like GPT-4. Maybe we should start doing more design experiments with how one could exploit such semantics? There's no reason to think that syntax-free writing ought to be ideal, any more than space-free and punctuation-free writing was the ideal form of writing which could not be improved...

Yes it does, so there's no reason to mark it up. The failure of the semantic web was trying to lower human text to the level the machine could operate on it. The success of LLMs is to raise the machine to level it can operate on ordinary human text.

You mark it up with the LLM so you can do something with it. A LLM like GPT-4 is still just emitting text tokens, it's not also generating pixels to push to your monitor. If you want to do something involving semantics like part-of-speech tagging, you'd obviously use the LLM to parse & annotate it, and then do stuff like use CSS to style nouns differently from verbs, or whatever. Maybe you don't distribute that, but run it locally, but you still have to do that at some point!

That's put bluntly but well.

I understand the parent's sentiment though. Every few years when I need to use Tex for something it always take me a second to remember that it is not a computer algebra system, just a rendering engine hyper focused on rendering 2D math notation that predates web rendering engines by about two decades. For some reason it surprises me that CSS did not grow to eat the publication rendering use case. I get that Tex has solved that problem quite well, but it seems like the sheer number of people who used CSS would mean that those capabilities would be ported to the language. But no, didn't happen. So we still have the two rendering languages.

> Marking up the semantic structure of all your mathematical formulas is about as likely as marking up the parse tree and parts of speech for all your regular prose sentences.

No. The semantics of math are simpler than English prose.

My above comment may not be useful or interesting. I'm not complaining; rather, I'm seeking feedback. Is there a strong substantive argument against what I said? I'm happy to be proven wrong, or to be shown that I'm missing the point. Learning and seeing a new point of view is more enjoyable that pointing out weak argumentation. I push back to see if there is any there there.

To the substance: If one wants to argue that Semantic MathML ("SMML") will not be adopted, one would need to define a metric. Then we can model and forecast. I don't think the parent poster nor I have the time or interest to do this. I'll leave this heady analysis to the mysterious proprietary commercialized no-one-gets-fired wisdom of the Gartner Magic Quadrant [1].

Now we shift to utility. To argue SMML is not useful, you have to explain the costs and benefits of specific aspects.

* Of course markup has cost, but what are they specifically? It depends on many things, but the key ones seem to be the format/markup itself and tooling to help with it. Hopefully we can steer clear of holy wars here (aka the semantic analogue of the tabs versus spaces forever-war).

* And what are the benefits? I see three intertwined benefits: driving out ambiguity, easier categorization, and improved reasoning. Reasoning over mathematics can help find mistakes, prove theorems, connect previously disparate proofs and even fields, and lots more.

I haven't seen a convincing argument against the value of such benefits, other than arguing against their likelihood. But the latter seems hollow; such benefits can and do happen with human minds reasoning over mathematics. It is clear that computers can assist, at the very least, and perhaps even lead. I'm inclined to think that AI can scale up mathematical reasoning beyond human capabilities, even if the AI is quite far from human intelligence.

One might argue impossibility of one purported benefit of reasoning. Of course, this is downstream of the for what question, above. In sibling threads, I see what seems to be a false equivalence between formalization of mathematics and English. That argument seems to imply that formalization is "too costly" or "too difficult" or possibly even impossible. It offers shallow dismissals of the benefits at best. In summary, it doesn't make a convincing cost versus benefits argument.

[1] https://www.theinformation.com/articles/the-tech-tussle-over...

> Presentational MathML is the only thing that matters; Semantic MathML is W3C semantic web wank.

No. There are situations where a semantic interpretation is beneficial. A simple example is ‘(x + y) / z’. The best rendering (inline or full line) depends on the context.

People can discuss the tradeoffs without exaggerations and calling names. Let’s try.

That's a presentational consideration, whether you want a fraction that can stretch into {a \over b} or shrink into a/b, or if it always stays a/b.

Semantics means whether the / denotes eg division of real numbers or a group quotient. Semantic MathML basically wants you to provide a URI pointing to the definition of / you are using, eg. http://www.openmath.org/cd/arith1#divide. This is nonsense and about as likely as getting humans to mark up every word in your sentences with a URL for the numbered dictionary definition of the word you are using.

Thanks; I stand corrected about my example of a/b.

> Semantic MathML basically wants you to provide a URI pointing to the definition of / you are using, eg. http://www.openmath.org/cd/arith1#divide.

A better example, thanks.

> This is nonsense...

Could you clarify (dare I say markup) which sense of 'nonsense' do you mean?

  1. spoken or written words that have no meaning or make no sense: he was talking absolute nonsense.
  2. foolish or unacceptable behavior: put a stop to that nonsense, will you?

I'm not trying to just be pedantic: driving out ambiguity has value; even more so in mathematics.

Whether a particular technical suggestion for reducing ambiguity seems practical to you is quite different from it being understandable from some point of view and/or having internal consistency; i.e. making sense.

Let's move away from squishy, vague notions comparing semantic math markup vs English markup. Let's talk about some objective differences:

* "who": audience: mathematicians appreciate and deal in formality orders of magnitude more than English-speakers in general (perhaps second only to lawyers and grammar teachers?)

* "what": First, dictionary size: 1600 in OpenMath vs ~600K English words.

* "how": For a particular math document, it is likely that each operators used tends to have a common semantic. So it would make sense to state a mapping from certain operators to their semantics up-front and reuse these definitions throughout the document. See the bottom of this comment for some ideas on how this might be done.

* "why" : computability / reasoning: If mathematical is sufficiently formalized, it can be reasoned over very effectively, limited only by the computational algorithms. Reasoning over English sentences is fraught because English is frightfully ambiguous.

Conclusion: the 'who', 'what', and 'why' differ substantially.

P.S. Regarding the "how" discussion, here is a conversation with ChatGPT 4.0:

> In Semantic MathML, what mechanisms (if any) exist so that one math document does not have to restate the semantics of a particular operator repeatedly?

> "In Semantic MathML, use the <csymbol> element and Content Dictionaries (CDs) to avoid restating the semantics of an operator multiple times in a document. The <csymbol> element refers to an operator in a CD, which provides the operator's semantics. This way, you can reuse the operator without redefining its semantics in the document."

> Please double check this.

> Apologies for the confusion earlier. In Semantic MathML, there isn't a built-in mechanism to globally define the semantics of an operator for the entire document. However, you can use XML entities to create a shorthand reference for operators, and their semantics can be defined using the <apply> and <ci> elements, which encapsulate the semantic content. This will help reduce redundancy while still preserving the semantics of the operators throughout the document.

I'll spare you the rest of the chat log; the syntax is not pretty.

Semantic MathML is not useful. Consider a simple statement like

> Given any positive integers r and k, there is some number N such that if the integers {1, 2, ..., N} are colored, each with one of r different colors, then there are at least k integers in arithmetic progression whose elements are of the same color.

The majority of the semantics of this statement are part of the prose. Even having perfect "semantic" information about the formulas gets you absolutely nothing. You cannot reason about this without being able to reason about human language in general like a human can, in which case you do not need the "machine-readable semantics" of MathML at all.

The division of math into "ambiguous" English and "formal" formulae/symbolism is semantically artificial. Both of these are human languages. There is not some fully marked up form which is mechanically unambiguous that you can produce if you try hard enough. Presentationally the distinction is that special typesetting facilities are needed for the appearance of mathematical formulae and this is why presentational MathML is useful, but the semantics flow from the same source that the semantics of all written language flow from. It is not fundamentally different than, say, an Egyptologist who requires special facilities to typeset hieroglyphics.

> The division of math into "ambiguous" English and "formal" formulae/symbolism is semantically artificial. Both of these are human languages.

I'll grant the obvious: both are human languages. But what does this assumption prove? It certainly does not prove that math is not formal.

>> Given any positive integers r and k, there is some number N such that if the integers {1, 2, ..., N} are colored, each with one of r different colors, then there are at least k integers in arithmetic progression whose elements are of the same color.

> The majority of the semantics of this statement are part of the prose.

The semantics can be expressed as prose if you like. They can also be expressed formally. As you know, 'color' is used here for the convenience of the reader. The underlying semantics works independently of the English notion of 'color'. You know this. What do you think is not formalizable about your example? "Given / assume": no problem. Introducing variables: no problem. Specifying variable types: no problem. Various mathematical structures (sets, sequences): no problem. "there are / there exits": no problem. "at least": no problem. And so on.

> Even having perfect "semantic" information about the formulas gets you absolutely nothing.

You have shared some good counterarguments, and I appreciate it, but "nothing" is an exaggeration here. It doesn't advance your argument.

> You cannot reason about this without being able to reason about human language in general like a human can

This is incorrect. You sound knowledgeable about mathematics, so I'm quite surprised you would make such a claim. Are your emotions (perhaps a loathing of Semantic MathML? -- your comments suggest this story) clouding your logic here? Deductive reasoning is well studied in computer science. To state a previous point again: there are many formal systems that can be reasoned over to various degrees. Such systems are still useful and quite different than English.

> Semantic MathML is not useful

Earlier, you said it was both nonsense and unlikely to ever work. Now you say it is not useful. You are moving the goal posts. Your comments have had a mix of thoughtful examples (thanks) with some exaggeration and rant. I'm trying to tease these apart, but it isn't easy. I can see you have a strong negative reaction to Semantic MathML, but so far, your writing hasn't been persuasive.

MathML is faster to render. KaTex is a lot faster than MathJax but the difference remains noticeable. (Firefox extension to force native MathML rendering: https://addons.mozilla.org/en-US/firefox/addon/native-mathml...)

You can pre-build katex, or render server side.

That's better, but it generates a lot of markup, causing the sites to be very heavy (several megabytes). I know this because I'm using pre-rendered KaTeX to write my school notes, see for example: https://kmlinux.fjfi.cvut.cz/~blazead5/school/difr/ Notice that the page takes a while to load, even though it's mostly text.

It loaded in about 3s for me, on Android.

Well, it depends on your connection speed and whether your browser supports gzip compression (which hopefully most browsers should at this point).

Igalia is doing amazing work shipping native MathML support for Chromium based browsers.

https://www.igalia.com/2023/01/10/Igalia-Brings-MathML-Back-...

KaTeX is really old (like 9 or 10 years?). So if it was going to kill MathML, it probably already did it.

I’m TeX parlance, that makes it an infant.

MathML was never alive to be killed. It's MathML that might kill Katex (with Chrome's recently improved support), not the other way around.

I believe MathML is still the only way to get proper math typesetting in epub, and I doubt katex is an option.

Unfortunately MathML doesn't get you proper typesetting in epubs, so it has that in common with katex.

It does if your EPUB reader supports it—which most don't, but a few do! I am partial to http://koreader.rocks/

I have tried out a few readers, none I tried so far support it in satisfying quality comparable to what katex would deliver. Maybe koreader is an exception, but I doubt it. Will give it a try at some point.

> (...) comparable to what katex would deliver.

You're comparing real world working implementations based on mathml with your hopeful expectations of how you wish katex could work in an epub implementation.

It's good to have hopes and dreams and a positive outlook, but your perceived solution does not exist. It's hardly relevant to present it as a better alternative.

I have no need for real-world implementations that do not work as well as I need them to work. KaTeX is proof that math can be displayed properly in a browser-like environment. Anything less will not do it, at least for me. That's why I have exclusively PDFs in my digital library, except for books that are just text, like fiction.

No hopes and dreams needed, just use PDF. But making epub work properly for math is not a problem in principle, just make katex work in an epub reader, problem solved.

And people who are satisfied with substandard solutions are actually part of the problem, not the solution.

> just make katex work in an epub reader

"Just write a full JavaScript and DOM implementation for your resource-constrained e-ink device"

I think you need that already if you want a compliant epub reader. Javascript is part of the epub standard.

According to the standard, it seems that basic MathML support is required for all conformant implementations (https://www.w3.org/publishing/epub32/epub-contentdocs.html#s...), but scripting support is optional (https://www.w3.org/publishing/epub32/epub-contentdocs.html#s...).

Not that anyone actually follows the standard…

And that's one reason why the majority of ebooks purchased by consumers aren't in epub format.[1]

For the vast majority of fiction a format constrained to bold, italicize, paragraph break, chapter heading, and chapter break allows a far superior user experience.

[1] https://magnoliamedianetwork.com/ebook-publishing-platforms/

JavaScript isn't a necessary component of ePub readers. Besides a handful of apps like Adobe Digital Editions and Apple iBooks, most don't. Kobo doesn't in their eReaders. JavaScript is only used in ePubs for multimedia crap. Fiction ePubs don't bother either.

Kindle books generally start their life as ePubs that Amazon then converts to their formats before they list them. They don't even let you publish in mobi anymore.

Kindle's lack of MathML support actually makes the user experience worse for everyone. Publishers often make 1 ePub they submit to multiple stores so rather than make a MathML version and a shitty image version for Kindle they just make a shitty image version and now you have a math textbook that's larger than the PDF would have been AND the equation text isn't resizable defeating the whole point of a reflowable ebook.

> Kindle books generally start their life as ePubs that Amazon then converts to their formats before they list them. They don't even let you publish in mobi anymore.

Morally speaking they start as Kindle ePubs that support a very very limited subset of the ePub standard.

Also want to note that this is not a matter of resource constraints: The implementations of MathML for (desktop) browsers are just as shitty.

If you need it to be pixel-perfect it will probably disappoint, yes. It's good enough for the few times I have made use of it. (It's also open-source, so you can always contribute improvements)

Never understood that need to contribute to open-source. Why would I try to meddle with somebody else's messed up implementation? I have enough messes of my own to clean up!

Team work makes the dream work.

Must be why Avenger movies are so popular.

> Team work makes the dream work.

Except there is no team, and people dream differently.

More often than not, open source creates problems for developers. See Rust's Actix framework.

> Unfortunately MathML doesn't get you proper typesetting in epubs (...)

Wrong. MathML is a part of the Epub3 specification. All e-reader implementations that comply with the epub3 specs get you proper typesetting in books published in epub3 format.

I guess it is you that is living in a dream world. There are no epub3 compliant implementations then, because none of them display math properly. If they were compliant, they would also run KaTeX just fine, because Javascript and HTML are part of the standard, too.

> I guess it is you that is living in a dream world. There are no epub3 compliant implementations then, because none of them display math properly.

To start off, you already have posts in this very discussion rejecting your misconception.

Secondly, mathml works fine when we have an epub3 reader opening a epub3 doc created by epub3 generators from epub3+mathml input. If any of those requirements aren't met, you get issues. This happens with each and every single typesetting feature, not just mathml. Would you claim that epub fails to support tables if you open an epub doc with broken tables?

Thirdly, a typical implementation shortcut taken by epub readers is to reuse whatever WebView they pick. If your epub reader uses an outdated or shitty WebView implementation, you get shitty epub docs.

https://caniuse.com/?search=mathml

Why are you commenting on subjects you are clearly clueless about?

I think I will indeed refrain from commenting in the future, as conversing with people as knowledgeable as you are is becoming a chore.

Katex supports ahead-of-time server-side rendering which just generates HTML, so it may indeed be an option.

I am not that familiar with MathML, but I can imagine programmatically manipulate math expressions with MathML; can TeX math expressions be manipulated in the same way?

Reply on news.ycombinator.com