Bringing MathML back to Chromium
igalia.com
igalia.com
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...
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):
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.
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...
?
* 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:
<math-up>ln x = int_1^x 1/t dt</math-up>
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.
\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 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).
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...
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/
Paraphrased: It doesn't make money, so why do it?
[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...
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