15 ms·
MathML Progress
- mkotowski 5y ago> As promised, after a short break, we have also renewed our work on upstreaming MathML-Core in Chromium. […] You can try these for yourself in Chrome canary by enabling experimental web platform features. Finally! The lack of MathML support in Chromium based browsers was quite frustrating to me. Though, it will be probably still quite a lot of time before the libraries like MathJax and KaTeX became redundant for basic use cases.
- ubavic 5y ago> Though, it will be probably still quite a lot of time before the libraries like MathJax and KaTeX became redundant for basic use cases. I think that libraries like MathJax and Katex will always be used for translating TeX notation to MathML. Stil, I look forward to day when will have native rendering on all browsers.
- oefrha 5y agoJust tried https://fred-wang.github.io/MathFonts/mozilla_mathml_test/ https://fred-wang.github.io/MathFonts/mozilla_mathml_test/ in Canary with enable-experimental-web-platform-features. As they say, the stretchy characters (e.g. think \left, \middle, \right in LaTeX) all have wrong heights at the moment. Still, that's a lot of progress made. Edit: Actually, when I select any font other than "Default fonts (local only)", the stretchy characters' heights change in response to content they embrace (though still not correct -- they tend to be taller than they should be), unlike with "Default fonts (local only)" where the characters won't stretch at all. I wonder why this is the case.
- globular-toast 5y agoWhy is the goal to make it look exactly the same as TeX? TeX is great but it's rules are based on Knuth studying existing typesetting and I'm sure a lot of rules are fairly arbitrary. When I look at this in Firefox it looks finished. Brace heights don't change the meaning of the mathematics. It's a purely stylistic choice.
- oefrha 5y agoKnuth didn’t arbitrarily make stylistic choices, he followed long established conventions in mathematical handwriting and printing where possible. IIRC he explained this at the beginning of The TeXbook. In this specific case though, it’s not hard to realize that parentheses, braces, radical symbols, etc. two ems taller than necessary both waste a lot of vertical space and look like crap.
- MontyCarloHall 5y agoI think the nearly 25 year effort spent on MathML should have been put towards standardizing browser engines natively rendering LaTeX à la MathJax. The initial vision of MathML was that people would write it in a WYSIWYG editor (since it’s far too verbose to write by hand), but that grossly misjudged users’ preferences—LaTeX is the lingua franca of mathematical typesetting, and people much prefer writing (and reading) LaTeX. Realizing this over a decade(!) after MathML was first introduced in 1998, the MathML community has since focused some of their efforts on LaTeX conversion, which raises the question: why not just focus on rendering LaTeX directly, rather than translating it to (and maintaining standards for) a clunky intermediary format no human will ever directly read or write?
- mkotowski 5y agoHaving MathML being XML based plays rather nicely with both HTML and SVG. And I am saying that while not being exactly a fan of XML-based formats. > The initial vision of MathML was that people would write it in a WYSIWYG editor (since it’s far too verbose to write by hand), but that grossly misjudged users’ preferences To be honest, it probably depends heavily on a particular audience. I know people who barely wraps their heads around the concept of BBCode, and those (although a much smaller group) who would probably advocate for exchanging Microsoft Word for a LaTeX editor. Most people out here are probably completely content with a WYSIWYG editor and don’t care about the inner mechanism of its implementation as long as it gives an expected effect for them.
- MontyCarloHall 5y agoYou can use a WYSIWYG editor to produce LaTeX (e.g. LyX). Regarding your point about ease of embedding in HTML/SVG, we embed other formats in markup all the time, e.g. CSS/JavaScript/images/etc. with nary an issue. MathML is the equivalent of having to compile CSS/JavaScript into an XML-based “bytecode,” which then gets parsed and executed by the browser.
- Y_Y 5y agoIn this case though, the people who need to typeset a lot of mathematics are more likely in the LaTeX camp.
- chobytes 5y agoNot sure who this is for. The notation looks extremely verbose and unusable, and latex won a long time ago already.
- h8hawk 5y agoJust ease of installing and standardization would rule out latex. Latex packaging is nightmare. Verbosity will be solved by tones of JS and python packages.
- jimhefferon 5y agoThe two > Latex packaging is nightmare. and > Verbosity will be solved by tones of JS and python packages. seem at odds to me.
- chobytes 5y agoAnecdata, but thats not been my experience. Ive found latex to be a much smoother experience to use than languages like js or python.
- snicker7 5y agoMathML is the only accessible option. Screen readers work with it. Tools like KaTeX output both HTML and MathML simultaneously (HTML for rendering, MathML for screen readers), leading to massive page bloat. MathJax requires client-side JS to look good, which is a big 'no' for me. Right now, there is no way to display math on the web that: (1) is accessible, (2) works across all modern browsers, (3) is not slow or bloated in some way. MathML in Chrome fixes basically all these problems.
- YetAnotherNick 5y agoI am not a blind but I would much prefer hearing latex formula word by word than whatever alternative they came up with(e.g "a slash pm b" or "slash frac a b"). I really doubt you can unambiguously say long formulas lot more succinctly. Even after having looked at the formula, I can't follow a lecture without having to look at the board and that is human translation which would be better than MathML.
- Abhinav2000 5y agoMathML, like other XML syntax languages, are more meant for computers to read & interpret - not for end users to write. I hope it becomes native across all browsers (as its the best chance of standardisation we currently have), as good as MathJax is, we shouldn't be having to rely on a JS polyfill to render maths in a browser...
- the__alchemist 5y agoOk, but why? What's the advantage of having unwritable and unreadable syntax? Why shouldn't I be able to edit it directly? This difference in opinion (on a subjective topic) is causing a rift between MathMl's goal of a universal math-language for browsers are more, with a large chunk of the potential users who hate the syntax.
- nsajko 5y ago> advantage of having unwritable and unreadable syntax There's (in a way) a false dilemma at play here. MathML is unreadable because it's XML, but it is also possible to describe trees in more readable languages like S-expressions. Either way, it would be absurd to add TeX into a Web browser ...
- MontyCarloHall 5y ago> Either way, it would be absurd to add TeX into a Web browser ... I agree. Nobody is seriously proposing adding a full LaTeX implementation to a browser, but rather a parseable subset of TeX strictly for math markup, à la MathJax, which incidentally has become the de facto standard for embedding math in webpages.
- ubavic 5y agoBut who will decide what commands will be part of that subset? There are hundreds, maybe thousands, of commands that are used regularly in tex documents for displaying various forms of notation, and mathematicians still create new notation and packages for it. Most of the commands in MathJax aren't part of TeX, but LaTeX or even some popular package (amsmath, etc.). Some things are implemented in more then one packages, and those different implementation have differences (for example, in Russian books integral sign is different than one in American). If we implement a subset of TeX in a browser, there are two options: 1. If we only include the most used commands, such technology will be useless for professional mathematicians and probably be obsolete in future (when some new useful notation appears). 2. On the other hand, if we keep adding new commands for every type of mathematical notation, then we will need longer names for commands (or maybe namespaces) and notation will not be readable anymore. Not to mention that browsers maintainers will need a lot of work to implement all that (How long will that take?) Also, if we implement only a subset of TeX, users will not be able to easily (or anyhow) create new notation. On the other hand, MathML is very flexible in that regard and allows users to be creative. And, contrary to some other comments in this discussion, I don't think that code for mathematical notation must be human readable before all. Whatever approach you take (tex, XML, S-expressions), you will quickly find some examples that are horrendous for coding (integral inequalties, steps in PDE solution, commutative diagram, proof tree...)
- flakiness 5y agoChrome removed MathML long time ago and I thought that was the end of the story. But apparently Igalia folks didn't give up. I really appreciate and respect this level of persistence, and I'd give a bit of credit to Chrome folks as they don't at least reject their new initiative. I'm wondering who is sponsoring this work. Igalia is still a company and I don't think they are afford to do this as a hobby... But maybe they do this anyway?
- vitorsr 5y agoYou can find more information on the project website [1]. [1] https://mathml.igalia.com https://mathml.igalia.com
- mymythisisthis 5y agoI've played with MathML http://gron.ca/algebra/027.html http://gron.ca/algebra/027.html it's okish but LaTeX is better. A way of displaying math is needed on browsers. So is a better way of citation, and how about a video standard. Are we at an inflection point? Traditional math symbols will just be replaced by a computer language like Python? And we end up with 2 languages for doing math; the old paper way and the news computer programming language way?
- mindcrime 5y agoAs far as I'm concerned, this is great news. Of course I get the criticisms from the "MathML sucks" and "why not use TeX" crowd. And that's fine... I'm not even sure I disagree with those folks. But the big difference, to me, is that MathML-in-the-browser is here (more or less) today and is just shy of being ubiquitous and widely usable by most browser users. That is, IMO, a big deal. And the people who really, really, want something other than MathML are free to start (or finish?) writing code, raising money to have other people write code, etc., and work with Google, Mozilla, et al, and get their system integrated into browsers. I'd just be surprised if this effort yields any meaningful results in less than 20 years. So at least now we'll have native MathML rendering to tide us over until the New Math Browser Thing becomes reality.
- eterevsky 5y agoWhy start/finish writing code? There are already plenty of websites, starting [with Wikipedia](https://en.wikipedia.org/wiki/Help:Displaying_a_formula https://en.wikipedia.org/wiki/Help:Displaying_a_formula) that can display formulas and all of them are using some versions of TeX. I don't really see a point in working on MathML at this point.
- mindcrime 5y agoWhy start/finish writing code? I'm talking about people who want "native in-browser" rendering for something other than MathML. If they want their favorite approach implemented in the browser, they're welcome to make it happen. My point is that MathML native-in-browser rending is basically already here. Of course you can use Javascript libraries like MathJax or something similar to implement whatever you want. But for people who care about native rendering, that's neither here nor there.
- svat 5y agoThe existing ways of putting math on the web are all already here too, and have been for a long time. Apart from the old way of generating images by running TeX (still used by Wikipedia, for instance), both of the most common libraries used for typesetting (MathJax and KaTeX) can produce either HTML+CSS or SVG which are well-supported by browsers, and both of them (KaTeX since the beginning, and MathJax since version 3.0) can be run server-side so that no JavaScript needs to run on the user's browser. And regardless of whether or when the "native in-browser" rendering of MathML becomes good enough and widespread enough, the "native in-browser" rendering of HTML+CSS and SVG will continue to exist and be well-supported. (See the last section of http://bit-player.org/2020/mathjax-turns-3-0 http://bit-player.org/2020/mathjax-turns-3-0 for some interesting conclusions.)
- murkle 5y agoThe Chromium ticket is https://bugs.chromium.org/p/chromium/issues/detail?id=6606 https://bugs.chromium.org/p/chromium/issues/detail?id=6606 You can try it with chrome://flags/#enable-experimental-web-platform-features enabled here https://fred-wang.github.io/MathFonts/mozilla_mathml_test/ https://fred-wang.github.io/MathFonts/mozilla_mathml_test/
- dynm 5y agoA lot of people don't seem to get the point of MathML. Well, suppose you have a blog, and you want to use math. If it's going to be consumed on the web, a javascript library probably works OK. But if people subscribe over RSS/atom? Or over email? As far as I can tell, nothing works. Your best bet is to try to figure out how to write your math using unicode, or (the horror) to render everything to bitmaped images. Hopefully MathML will help with that. The most important thing is that MathML is limited enough in power that gmail et al. can support it without worrying about security / privacy. (Unlike, say, .svg images now.)
- leni536 5y agoI fail to see how MathML is inherently safer than SVG.
- dynm 5y agoI meant that as an aspiration: "I sure hope that MathML is designed/considered safer than SVG." Why exactly SVG is considered unsafe now, I'm not sure, but I understand that this is why gmail doesn't allow it. It seems like SVG can contain semi-arbitrary HTML and javascript? (I'd love to have a less-powerful but more trusted version of SVG, too.)