# MSC1722: Support for displaying math(s) in messages #1722

Open
wants to merge 4 commits into
from

## Conversation

Projects
None yet
7 participants
Member

### uhoreg commented Nov 15, 2018 • edited

 Rendered I keep switching between preferring MathML or LaTeX. This proposal proposes MathML, but investigates LaTeX as an alternative enough to hint as to what a fully worked-out LaTeX proposal might look like. This proposal is related to vector-im/riot-web#1945

Open

Member Author

### uhoreg commented Nov 15, 2018

 FWIW, to me, the question of whether to use LaTeX or MathML boils down to: would we rather make clients deal with the potential security nightmare of processing a Turing-complete language, or would we rather use a format that displays horribly for clients that don't understand it?

### Evidlo commented Nov 21, 2018 • edited

 MathML should also be listed as a supported input for KaTeX: KaTeX/KaTeX#593
Member Author

### uhoreg commented Nov 21, 2018

 MathML should also be listed as a supported input for KaTeX: KaTeX/KaTeX#593 That issue seems to be about rendering to MathML, rather than rendering from MathML. I don't see anything about using MathML as an input to KaTeX.

Member

### turt2live left a comment

 I love the detail into the alternatives here. Based on the information presented, Presentation MathML does seem to be the right answer, I think.

### jryans reviewed Nov 26, 2018

proposals/1722-math.md Outdated
Member Author

### uhoreg commented Nov 28, 2018

 Summarizing some considerations with MathML vs LaTeX: accessibility: Presentation MathML is not that great for accessibility, since it loses some of the semantics (e.g. $\binom{1}{2}$ becomes a fraction with linethickness=0, which loses the meaning of the expression). But some screen readers support MathML natively, and MathJax and KaTeX use MathML for accessibility when rendering LaTeX. I think that for some math, MathML would have better accessibility, whereas for others, presenting raw LaTeX code would be better, so there is no clear winner here, IMHO. fallbacks: Using MathML would force clients that don't support math to parse the HTML in order to ignore the MathML and extract the fallback information, whereas with LaTeX, the LaTeX code itself could be a reasonable fallback, or it can be embedded in a way that the fallback doesn't need any special processing from the clients. I think that LaTeX is the clear winner here. implementing display: or, if a client wants to implement displaying of math that it receives, and can't use a suitable library, how hard would it be to implement it? Implementing full support for either is pretty hard. However, the vast majority of math that people would be sending could be supported by supporting a smaller subset, and using a fallback rendering for displaying math that can't be supported. Most languages have an HTML parser (and if a client is already displaying the formatted_body, then it should have access to an HTML parser), so supporting MathML would be a matter of supporting individual MathML elements and attributes, which can be done incrementally. However, for LaTeX, it is likely that a client author would need to implement a TeX parser from scratch, and although it would probably not need to be a full TeX parser (e.g. it wouldn't need to implement things like \makeatletter), this would be extra work. This, along with the security considerations below, may discourage client authors from trying to implement math support. MathML seems to be the winner here. implementing math input: If clients want to present some sort of fancy GUI for entering math, either format is probably equally easy to generate (although there may be existing libraries for input that will generate one but not the other). However, most clients will likely want to allow users to enter math using LaTeX since it is already a common format for math input, and is not too difficult to use. So clearly, if we use MathML, the client would need to convert from LaTeX to MathML, whereas if we use LaTeX, then the client does not need to do any conversion. LaTeX is the winner here. security: MathML is just XML and does not introduce any new vulnerabilities, since clients are parsing HTML anyways. On the other hand, LaTeX is Turing complete, and malicious input could cause a LaTeX implementation that is not carefully written to behave unexpectedly. Most well-known libraries should be safe (with the notable exception that using latex itself would be very unsafe), but new implementations may be problematic. MathML seems to be the winner here. MathML and LaTeX both have advantages and disadvantages. I think that the answer to which one is the best to use depends on the relative weights assigned to different factors.
Contributor

### Half-Shot commented Nov 29, 2018 • edited

 So for fallbacks, I'm strongly inclined to want a thumbnail (optionally) as a fallback mechanism for dumb clients at the risk of it looking a little unclean. That might help solve the ugliness around MathML fallbacks, although admittedly clients need to know to display the fallback (extensible events where art thou?). Looking at the langauges side by side though, I am deeply concerned with how verbose MathML is and it would likely bother folks to have to write a load of XML for a similar string of LaTeX. That's actually quite a major drawback for me as I don't see client's willing to spend a long time implementing complex UIs (at least initially) and this might severely reduce the pacticality of this event.

Contributor

### Half-Shot commented Jan 18, 2019

 Hey @uhoreg, do you have a status update for this?
Member Author

### uhoreg commented Jan 18, 2019

 Hey @uhoreg, do you have a status update for this? I've been focusing on E2E stuff lately. I'll probably try to poke at this again in Feb.

### eMPee584 reviewed Apr 1, 2019

 However, this only works for certain notation when using only the subset of HTML allowed by Matrix, and requires that users have a font installed that supports the necessary characters. Most importantly, one cannot write matrices using this method, and failing to support matrices in a protocol

🤣