Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
7 participants
@uhoreg
Copy link
Member

commented Nov 15, 2018

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

@uhoreg

This comment has been minimized.

Copy link
Member Author

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?

@uhoreg uhoreg changed the title Support for displaying math(s) in messages MSC1722: Support for displaying math(s) in messages Nov 15, 2018

@Evidlo

This comment has been minimized.

Copy link

commented Nov 21, 2018

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

@uhoreg

This comment has been minimized.

Copy link
Member Author

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.

@turt2live
Copy link
Member

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.

Show resolved Hide resolved proposals/1722-math.md Outdated
@uhoreg

This comment has been minimized.

Copy link
Member Author

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.

@Half-Shot

This comment has been minimized.

Copy link
Contributor

commented Nov 29, 2018

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.

@Half-Shot

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2019

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

@uhoreg

This comment has been minimized.

Copy link
Member Author

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.

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

This comment has been minimized.

Copy link
@eMPee584
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.