MathML always seemed like a waste of time. It was/is objectively worse on every axis (at least from a user perspective) compared to the long-established LaTeX notation.
I don't think MathML is designed for human creation, it's somewhat human readable but I believe the main goal was to remove the possibility of ambiguities.
It was designed explicitly to be written by other programs, to the point that they have an "error message" element for when your latex-like parse-and-output-mathml program failed, whose example in the spec is "Syntax error: \frac{1}": https://www.w3.org/TR/mathml-core/#error-message-merror
This is just wrong. MathML is not about notation, it is about rendering. Notation is secondary (as is evidence by the number of translators out there). Having native rendering yields numerous benefits including:
* Less works for developers who no longer need to pick, integrate, and maintain a third party library for rendering.
* Faster user experience, as the MathML code can be served directly and rendered by the browser (as opposed to parsed and rendered with the javascript engine).
* More options. Maybe LaTeX is not the right choice of syntax (more people write math then professional mathematicians and PhD students). As translating to LaTeX is hard, translating to MathML is easier (I know, I’ve written one my self).
Maybe something similar to Troff eqn language? Or the formula language in Libreoffice Math? Both of these are a bit more approachable than LaTeX's math
mode, IMO.
I think the LO Math formula language is nearly an exact implementation of eqn. I prefer eqn to LaTeX because it is easier to remember/write/read, but complex equations tend to take some fiddling to avoid ambiguities.
The point is that MathML is easier to translate to then many of these other languages. I wrote a language my self a few years ago that translates to MathML (https://runarberg.github.io/mathup/) and MathML was an absolute joy to target.
In mathup I included a second target to update the DOM directly .toDOM() and .updateDOM(oldMathNode) instead of .toString(). This would have been quite difficult if there wasn’t a nice mapping between the language and the DOM nodes. By implementing math in MathML browsers have made it easier for us software authors to write these other languages that serve different purpose then LaTeX. Our users benefit from this proliferation. Ultimately they don’t need to know which language is the native one, because all they write is:
I think UnicodeMath [1] is really interesting and approachable and is a standard that Unicode themselves have been keeping an eye on/helping maintain. It takes advantage of the richness of Unicode in interesting ways that makes the formula encodings in plain text better resemble their formatted counterparts. (You just have to forgive that the standard originated from the Microsoft Office team.) The interesting thing to me that UnicodeMath partly implies is the idea that math formatting could be considered similar to "regular font rendering" in a similar way to how ubiquitous emoji have become.
> * Less works for developers who no longer need to pick, integrate, and maintain a third party library for rendering.
> * Faster user experience, as the MathML code can be served directly and rendered by the browser (as opposed to parsed and rendered with the javascript engine).
Those two wouldn’t be there _if_, as the OP suggested, browsers would have supported a TeX-like way to render math instead of MathML.
Yeah but TeX has problems on its own which makes it a poor choice as a native language. E.g. if you wanted to create an anchor inside your expression, or apply some DOM manipulations. Then there is the whole problem of TeX not having a clear specification, and being turing complete. Both issues make it a noop for browsers to implement as a markup language. Like if you wanted to dynamically change the color of the denominator in the expression 1/x. Which node would you target, and which attribute would you change, and to what, in your script if the expression markup looks like this:
\frac{1}{x}
How about now:
<mfrac>
<mn>1</mn>
<mi>x</mi>
</mfrac>
MathML is a lot easier for library authors target and for web developers to work with, which makes it a superior choice as a native language to TeX.
User as in reader? That's definitely not true. It becomes integrated into the document (vs a rasterized image), can copy/paste, etc.
User as in author? That's true, but latex -> mathml conversion already exists and is decent, and will get increased attention now that the major browsers all support it to a baseline level.
FWIW a rasterized image isn't LaTeX any more than a rasterized image is MathML. Both are markups and both can (and are able to) be rendered into the document in a way they are selectable, sharply resizable, and so on.
Characterizing LaTeX as a rasterized image is really putting up a straw man - MathJax and similar have existed for a long time.
As a reader of raw markup, LaTeX is much much more readable than MathML.
As a human writing the stuff, MathML is basically unusable.
If you're using some gui/whatever then the backend format is just a tooling issue - why opt for the one that is obtuse for humans to interact with? It's very similar to the reason why we've evolved from HTML to markdown and the like - XML is terrible to interact with if you're not a computer. And even if you are a computer, there's a seeming preference for json, yml and the like over XML as it's human readable/modifiable.
Sadly, TeX is (today) wedded way too much to the PDF format, which not only has tons of baggage, but also is not really appropriate for digital documents.
HTML is probably the best digital document format we have, and hopefully more people will try again to make it into a self-contained document format :
(EDIT : oops, at least it used to use MathML, I guess they might have made it optional considering the lack of support by Chrome ?)
Also, LaTeX specifically has the issue that a LOT of its tooling has poor Unicode support, though Lua(La)TeX and Xe(La)Tex are trying to make that better.
MathML has more capabilities than the ad hoc notation of LateX simply in virtue of being XML-based. Whether these capabilities are ever realized is another question, but LaTeX had a pretty big head start and better tools.
This confuses me... TeX and LaTeX by extension are entire programming languages, in terms of _capability_ MathML is to LaTeX what JSON is to Javascript - just a representation of the final output, rather than the logic to produce it.
That said I think just having a universal "target" format for formulae will make things much better (much like JSON itself is an "advancement" in it's own right,
because of the easy interoperability it unlocks).
Indeed. That’s the sense that I get as well. MathML is ultimately about rendering but not the language, but they had to pick a language, so they picked one that was easy to translate into, and had a nice mapping to the DOM structure.
LaTeX is nice to write until it is not, like you need an equation block or tables or wants to generate an equation programatically. And it goes through a mysterious backend engine that renders something that is correct 90% of the time.
MathML's removal in 2013 in Chrome was a huge deal in the accessibility community. Fixing the bugs and vulnerabilities of MathML in blink would have been entirely possible with Google's resources. In hindsight, it's easy to see why—now we consider Google an ad company first—but back then it was truly bewildering, given that Firefox continued their support of MathML.
There was a big push at the time for native presentational MathML, and Chrome basically undercut it completely. MathJax picked up some of the slack, but it was never a true replacement. Either way, it's nice see presentational MathML is back.
> MathML's removal in 2013 in Chrome was a huge deal in the accessibility community
That sounds ahistorical to me. Maybe removal of the (potential) promise of future MathML from Chrome was a huge deal?
MathML support across browsers in 2013 was very spotty and buggy (there's a reason that even back then MathJax didn't prioritize MathML output), but the accessibility story was atrocious.
"Ahistorical" is not the word you're looking for, and even if it were, you're incorrect.
Firefox and Internet Explorer (with a third party plugin) both had support for MathML reading for screen readers. The support wasn't complete, but it was good enough for high school level math in HTML textbooks. I produced several dozen of these, so I should know.
> "Ahistorical" is not the word you're looking for, and even if it were, you're incorrect.
In the sense that there were certainly people lamenting the feature loss, yes, in the sense that there were large parts of the accessibility community actually using MathML and left without an alternative, no. It was largely not usable (Igalia has been fixing MathML bugs in Firefox and WebKit as well), let alone in an accessible fashion.
> The support wasn't complete, but it was good enough for high school level math in HTML textbooks
Maybe basic algebra, but that would be it. The document I linked gives some good basic examples even screen readers today trip over due to their inherent ambiguity (as rendered and/or as markup). Anything beyond that you currently have to annotate yourself, and you can do that just as easily without a native markup dialect.
Second paragraph of the Google 2004 financial report (first paragraph described what Google is):
We generate revenue by delivering relevant, cost-effective online advertising. Businesses use our AdWords program to promote their products and services with targeted advertising. In addition, the thousands of third-party web sites that comprise our Google Network use our Google AdSense program to deliver relevant ads that generate revenue and enhance the user experience.
In 2013 it was not a commonly held position that Google was primarily an ad company.
It's neither here nor there, but it's worth mentioning that Google as a search engine was around for five years before that SEC filing. As I'm sure you remember, that was a very long time in the history of the Internet to that point. Plenty of time to build good will and ruin it later, as we saw a similar pattern with Chrome years later.
Google was routinely referred to as "one-trick pony" already by the end of 00s due to the obvious fact that 95% of its revenues were from search ads.
IMO the difference is that many people perceived it as a benign deal - someone would take money from the advertisers and use it to actually make a better product for the users. It took a while for enough people to realize that this very reliance on ads means that "better product" from Google's perspective is not necessarily better for the users.
I get what he means. Back in the day I naively looked at Google like it was some kind of technology Santa Claus. Giving a decent email client to the people. Fighting of big bad Microsoft IE with a standard compliant browser etc. As a teenage programmer I hoped I could some day work for Google (or develop games). How things have changed... (still would like to create a game though)
That might be the most pragmatic and convenient answer, but comfort is the death of joy. A life truly lived aught to include some decisions that from the outside might seem ridiculous.
Depends on your value system, really. Some people would find working for an advertising company like Google to be unethical, even though it would probably pay more and have a better work-life balance.
The games industry's biggest problem isn't even crunch anymore. It's sexual harassment. I imagine there are a lot of people here who would view long hours as a viable trade-off to make a creative work but not have the same view towards, say, your boss being a sex pest.
I get the frustration, but MathML was and is still extremely buggy in Firefox. I would get hard crashes of the entire browser on MathML sites in Firefox and this was only a couple months ago.
Congratulations to the igalia team here for amazing work. I’ve been waiting to use MathML natively for years and thanks to a lot of hard work this is finally possible.
I'm a big believer of treating mathematical notation as a first-class citizen on the web. This won't make me jump ship to a Chromium-based browser, but I'm glad to see it happen.
100% this. Bit for bit math is the densest representation of knowledge invented by the human mind. Its a pity so many people switch off and never "get it" as they crawl in our current educational systems. Maybe making it easily available on the web will help at least a little.
> “This is the first example I know of that a major, major feature is really coming to the Web despite there not really being a business case for the business that normally advance the Web,” said Rick Byers of the Chrome team at Google.
Igalia isn't a major money maker. It's barely a large company. But they were able to ship MathML in Chromium. Sure, they have over a decade of experience on working on web browsers, and I'm sure that played a role here, but is that the only reason they were able to work on something like this? Is Igalia special for being willing to put their own money towards improving the web, without an obvious return on investment?
> Is Igalia special for being willing to put their own money towards improving the web, without an obvious return on investment?
Just to be clear:
> monetary support from the National Information Standards Organization (NISO) via a grant from the Alfred P. Sloan Foundation, Pearson, and APS Physics
> [In Igalia] we have the ability to submit for investments for things that nobody is currently funding but we think deserve funding and deserve to move forward somehow. [...] Initially this came up about doing some work on MathML in WebKit [sic; Blink presumably]. That was years ago. We sponsored all that work, funded all that work, got it done. And then, there was another effort there to try to drive something forward enough to make a proposal and maybe fund it through grants and crowdfunding. So we did an initial thing based on also writing a grant and getting initial money for the project from the National Institute of Standards Organizations and the Alfred P Sloan Foundation. [...] Then we also got small amounts of funding, few thousands from Pearson and APS Physics. And then there was a period where there was no more funding to be had for about a year, year and a half. And so Igalia stepped back in and funded the work. It slowed down slightly toward the end there, but we kept it going the whole time. And then we started Open Collective.
> It seems like some of the work that Igalia did was externally funded, but far from all of it.
Yes, that's right. Very far from all of it, but we're also very appreciative of those who did contribute funding. (I'm from Igalia/the host you're quoting)
> about doing some work on MathML in WebKit [sic; Blink presumably
It's a bit of a weird quote because it's not at all apparent how business cases for markup features would be decided on. Chrome is full of stuff that isn't obviously beneficial to Google's core business (WebXR? WebMIDI?), yet MathML is about enhancing the parseability of information in crawlable documents which you'd expect to be a priority for a search company.
That's not good for Google though. They have an incentive to not allow fingerprinting, both because it's illegal so they don't do it, and also because most people are logged into Chrome so they don't need to do it.
Do you have a source on fingerprinting being illegal? A lot of website privacy policies mention that they will collect "information about your device hardware configuration" or similar language.
EU GDPR says otherwise. Furthermore, using fingerprinting to bypass do-not-track functionality (e.g. Apple's App Tracking Transparency) will get you slapped with an FTC fine or lawsuits. Hell, Google knows this intimately, because they got caught bypassing P3P[0] with a bogus privacy policy string[1].
[0] P3P, or Platform for Privacy Preferences, is an obsolete standard for specifying machine-readable privacy policies from a combination of standard attributes. IE6 enforced it, AFAIK.
I'm in for MathML, but could it be just a loadable JavaScript component instead? Considering the usage frequency of MathML, a built-in browser implementation looks kind of wasteful.
MathJax is that, but it has issues with being an additional downloadable script, not fully integrating with accessibility, css, copying, etc. There are also some things like stretchable brackets that are hard to implement outside the browser.
- Formula content works well with browser UI: zooming, select, copy & paste, find text, etc.
This alone, to me, is good enough reason to be excited for the return of native MathML rendering to Chrome.
Now let's just hope this work gets propagated to Edge as well. Firefox, Chrome and Safari will now all have at least decent MathML support and since Edge is based on the same underlying engine as Chrome, there doesn't seem to be any obvious reason why MS wouldn't enable such support as well. fingers crossed
The issue with WebSQL was, and still is, that it is basically impossible to standardize, as you wouldn't get multiple different implementations, but just one that all browsers use as a library. The main task of a browser is not to provide an SQL API client side, but to display interactive documents, so you won't find the bandwidth for browsers to build multiple SQL implementations, and the existing ones have quite big incompatibilities to each other.
It's a manufactured issue that is rather absurd on its face. If SQLite is so popular that literally everyone ships it and nobody even wants to talk about writing an alternative, then take it and standardize it as is, or at least some sensible subset of it. It's probably the most open and portable codebase of notable size in widespread use worldwide, so any portability concerns are extremely hypothetical, while the productivity losses from not having a portable relational store in the browser are very real.
I implemented MathML as web components a few years ago as a work around. It wasn't super hard, but a native implementation provides so much better accessibility (and, likely, perf) https://github.com/pshihn/math-ml
jsMath, now MathJax, took all the wind out of MathML’s sails by rendering LaTeX equations in the client. I know that MathML is better in some ways, but the combination of downloading custom fonts and JavaScript-based layout solved the problem well enough.
My understanding was that the early versions of jsMath/MathJax started by converting LaTeX to MathML in the brief few years of relatively common browser MathML support and still uses something very like MathML for internal representations and still supports MathML as the output format.
One important aspect the work Igalia/Fred/etc did here was defining how MathML should render in browsers. Previously was this undefined[1], and working through all the integration points with CSS/HTML in the new MathML Core spec[2].
The next largest part was writing all the tests for this work, e.g. making sure that margin/border/padding worked consistently between all the MathML elements[3].
Arguably the implementation in Chromium was the "smallest" part of the work required here.
Congrats to Fred/Igalia/MathML-CG and all those involved. :)
78 comments
[ 3.3 ms ] story [ 168 ms ] thread* Less works for developers who no longer need to pick, integrate, and maintain a third party library for rendering.
* Faster user experience, as the MathML code can be served directly and rendered by the browser (as opposed to parsed and rendered with the javascript engine).
* More options. Maybe LaTeX is not the right choice of syntax (more people write math then professional mathematicians and PhD students). As translating to LaTeX is hard, translating to MathML is easier (I know, I’ve written one my self).
In mathup I included a second target to update the DOM directly .toDOM() and .updateDOM(oldMathNode) instead of .toString(). This would have been quite difficult if there wasn’t a nice mapping between the language and the DOM nodes. By implementing math in MathML browsers have made it easier for us software authors to write these other languages that serve different purpose then LaTeX. Our users benefit from this proliferation. Ultimately they don’t need to know which language is the native one, because all they write is:
And let the library translate to MathML for them.[1] https://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.1....
> * Faster user experience, as the MathML code can be served directly and rendered by the browser (as opposed to parsed and rendered with the javascript engine).
Those two wouldn’t be there _if_, as the OP suggested, browsers would have supported a TeX-like way to render math instead of MathML.
User as in author? That's true, but latex -> mathml conversion already exists and is decent, and will get increased attention now that the major browsers all support it to a baseline level.
As a reader of raw markup, LaTeX is much much more readable than MathML. As a human writing the stuff, MathML is basically unusable.
If you're using some gui/whatever then the backend format is just a tooling issue - why opt for the one that is obtuse for humans to interact with? It's very similar to the reason why we've evolved from HTML to markdown and the like - XML is terrible to interact with if you're not a computer. And even if you are a computer, there's a seeming preference for json, yml and the like over XML as it's human readable/modifiable.
Sadly, TeX is (today) wedded way too much to the PDF format, which not only has tons of baggage, but also is not really appropriate for digital documents.
HTML is probably the best digital document format we have, and hopefully more people will try again to make it into a self-contained document format :
https://www.russellbeattie.com/notes/posts/the-decades-long-...
The TeXmacs editor - not to be confused with TeX or emacs, exports and imports to HTML, thanks to MathML :
https://www.texmacs.org/tmweb/help/faq.en.html#general-1
For instance :
http://www.texmacs.org/joris/naw/naw.html
(EDIT : oops, at least it used to use MathML, I guess they might have made it optional considering the lack of support by Chrome ?)
Also, LaTeX specifically has the issue that a LOT of its tooling has poor Unicode support, though Lua(La)TeX and Xe(La)Tex are trying to make that better.
That said I think just having a universal "target" format for formulae will make things much better (much like JSON itself is an "advancement" in it's own right, because of the easy interoperability it unlocks).
There was a big push at the time for native presentational MathML, and Chrome basically undercut it completely. MathJax picked up some of the slack, but it was never a true replacement. Either way, it's nice see presentational MathML is back.
That sounds ahistorical to me. Maybe removal of the (potential) promise of future MathML from Chrome was a huge deal?
MathML support across browsers in 2013 was very spotty and buggy (there's a reason that even back then MathJax didn't prioritize MathML output), but the accessibility story was atrocious.
That's actually slowly changing for the better now. Some background and planning here: https://w3c.github.io/mathml-docs/gap-analysis/
Firefox and Internet Explorer (with a third party plugin) both had support for MathML reading for screen readers. The support wasn't complete, but it was good enough for high school level math in HTML textbooks. I produced several dozen of these, so I should know.
In the sense that there were certainly people lamenting the feature loss, yes, in the sense that there were large parts of the accessibility community actually using MathML and left without an alternative, no. It was largely not usable (Igalia has been fixing MathML bugs in Firefox and WebKit as well), let alone in an accessible fashion.
> The support wasn't complete, but it was good enough for high school level math in HTML textbooks
Maybe basic algebra, but that would be it. The document I linked gives some good basic examples even screen readers today trip over due to their inherent ambiguity (as rendered and/or as markup). Anything beyond that you currently have to annotate yourself, and you can do that just as easily without a native markup dialect.
Google has been an ad company way before 2013.
AdWords was launched in 2000. Google bought DoubleClick in 2007. https://en.wikipedia.org/wiki/DoubleClick
Second paragraph of the Google 2004 financial report (first paragraph described what Google is):
https://www.sec.gov/Archives/edgar/data/1288776/000119312505...It's neither here nor there, but it's worth mentioning that Google as a search engine was around for five years before that SEC filing. As I'm sure you remember, that was a very long time in the history of the Internet to that point. Plenty of time to build good will and ruin it later, as we saw a similar pattern with Chrome years later.
IMO the difference is that many people perceived it as a benign deal - someone would take money from the advertisers and use it to actually make a better product for the users. It took a while for enough people to realize that this very reliance on ads means that "better product" from Google's perspective is not necessarily better for the users.
Although by 2013, I'd say that even that was not an uncommon sentiment, especially since Google started doing stuff like this around then: https://commerce.googleblog.com/2012/05/building-better-shop...
?
Here you can have a look at the syntax as well as the corresponding results: https://www.w3.org/TR/mathml-core/
Maybe a LaTeX to MathML converter would be decent.
https://www.w3.org/TR/mathml-core/#the-top-level-math-elemen...
Paraphrased: It doesn't make money, so why do it?
Just to be clear:
> monetary support from the National Information Standards Organization (NISO) via a grant from the Alfred P. Sloan Foundation, Pearson, and APS Physics
(https://www.igalia.com/chats/mathml-release)
It seems like some of the work that Igalia did was externally funded, but far from all of it.
Yes, that's right. Very far from all of it, but we're also very appreciative of those who did contribute funding. (I'm from Igalia/the host you're quoting)
> about doing some work on MathML in WebKit [sic; Blink presumably
https://twitter.com/webkit/status/756489720893411329?s=20&t=... for example was also Igalia
[0] P3P, or Platform for Privacy Preferences, is an obsolete standard for specifying machine-readable privacy policies from a combination of standard attributes. IE6 enforced it, AFAIK.
[1] https://www.networkworld.com/article/2186056/google-says-ie-...
https://www.cio.com/article/296774/security0-google-sued-for...
However if you read here https://mathml.igalia.com/ There are obvious benefits to have it in the core
- Native implementation for efficient layout and automatic reflow.
- No external resources required except for purely stylistic information.
- Cross-compatible and high-quality rendering possible using TeX and OpenType MATH rules.
- Visual rendering fully controlled by font and CSS styling.
- Compatible with the other HTML5 technologies for best user and developer experience.
- Formula content works well with browser UI: zooming, select, copy & paste, find text, etc.
- Information properly exposed to assistive technologies
Is it wasteful? Maybe. Is it better? Sure. Also there is the question because MathML is a niche other browsers need to have fallbacks / polyfills.
This alone, to me, is good enough reason to be excited for the return of native MathML rendering to Chrome.
Now let's just hope this work gets propagated to Edge as well. Firefox, Chrome and Safari will now all have at least decent MathML support and since Edge is based on the same underlying engine as Chrome, there doesn't seem to be any obvious reason why MS wouldn't enable such support as well. fingers crossed
ax^2 + bx + c turns into: � � 2 + � � + �
HTML has those bad unicode characters too.
If no one uses it, it will eventually get phased out.
I have just about a billion <math> elements in the arXiv preview site I develop: https://ar5iv.labs.arxiv.org/
And that is just one site. PubMed will likely have more than that at some point: https://pubmed.ncbi.nlm.nih.gov/
The next largest part was writing all the tests for this work, e.g. making sure that margin/border/padding worked consistently between all the MathML elements[3].
Arguably the implementation in Chromium was the "smallest" part of the work required here.
Congrats to Fred/Igalia/MathML-CG and all those involved. :)
[1] https://www.w3.org/TR/MathML3/chapter2.html#fund.renderingmo... [2] https://www.w3.org/TR/mathml-core [3] https://wpt.fyi/results/mathml/relations/css-styling/padding...