MathML in Web Browsers

'MathML in Chromium' project is completed!

Tue, 10 Jan 2023 00:00:00 +0100

Igalia launched the ‘MathML in Chromium’ project in 2019 with the goal to allow native rendering of mathematical expressions in Chromium-based browsers. The hard work done over the past four years has finally paid off and today we announced that MathML is back in Chrome 109. We would like to thank all the people who helped us reach that milestone, and more specifically all the individuals and organizations who sponsored this effort!

This is, however, not the end of the story. Implementation work in web browsers will continue in order to fix bugs, implement new features, or improve interoperability. Please follow the Open Collective project page for future updates, and consider contributing to it if you’d like to help advance math on the web.

Igalia at BlinkOn 17

Fri, 18 Nov 2022 00:00:00 +0100

Early this week, Chrome developers from around the world gathered for BlinkOn 17. Igalia contributed several talks, including one about MathML. We announced the plan to ship MathML in Chrome 109, which will be released next January. For more details, you can watch the recording or read the slides of the presentation.

March 2022 - Sept 2022 Update - MathML-Core Support

Thu, 06 Oct 2022 00:00:00 +0200

In the last 6 months, quite a lot has happened with support from this fund, and additional work by Igalia. This included about 137 commits across many repos related to fuzzing, documentation, spec status, and interop.

In June, an Intent to Ship was filed in Chromium
Commits to improve MathML-Core interop in WebKit for dir, numalign, denomalign attributes
Commits to improve MathML-Core interop in Firefox for script-related features, the operator dictionary, invalid markup, semantics/maction, fontstyle/fontweight and numerous bits of cleanup
Many improvements to the MDN documentation, MDN content, Browser Compatibility Data, the MDN sidebar and MDN/webref CSS syntax data.

MathML-Core Chromium support mainstream release was delayed by some ongoing Chromium internals rework for LayoutNG creating a situation where support would have temporarily created a problem for anyone wanting to print MathML from existing sites with Chromium. Full support is currently scheduled for release 109.

Note: This post was originally published on the Open Collective project page.

Link to MathML updates

Thu, 23 Jun 2022 00:00:00 +0200

Although we haven’t published any update on this website since February 2021, we’ve continued to actively work on implementing MathML in Chromium and finally reached the intent-to-ship stage yesterday 🎉 ! Below you’ll find information about our progress:

MathML plans for 2021

Mon, 15 Feb 2021 00:00:00 +0100

It’s been a while since our previous update on the implementation of MathML in Chromium so we thought it was important to provide an update on what Igalia has (and hasn’t) been up to, and why.

One big thing that has been happening during this time has been that Igalia has been helping to coordinate and facilitate the the re-activation of the MathML WG in the W3C. Our aim has always been to not only ship an implementation, but to help define MathML-Core, resolving the initial historical challenges and setting MathML back on stable standards footing. As part of this, we helped draft a new charter, present things to a few different groups within the W3C, answer questions during the early review phase and, help gather votes and answer questions on the charter itself. You can view the charter, as well as see a presentation we did at W3C’s annual conference on this thread.

Last fall, our implementations reached a point where things weren’t quite ready to move on due to some pending re-work that was underway. Given the pending charter, some necessary wait time and a number of more immediate opportunities, a few of Igalia’s engineers temporarily reallocated most of their efforts to help advance on some other exciting web platform projects such as distributed web or :focus-visible. While severly reduced in capacity during this time, we did still manage to do some MathML implementation tasks (i.e. fixes or reviews in security & stability) and fix a serious integration bug regarding the fact that legacy layout was forced for MathML in SVG, fragmented or editable trees.

Since then, however, things are shaping up on the charter and pending chromium rework has progressed a bit and we believe it’s time to start talks on how we take this up again. Our plans are to return to this work part time during the second quarter. Let’s recap the current status and plans with respect to the initial roadmap :

Basic setup ✅
Basic Layout
- Basic HTML-like implementation of mtable ❌
Operator Dictionary ✅
Stretchy operators
- Stretch logic in <mrow>-like elements and under and over scripts. ❌
- Using stretchy and symmetric attributes. ❌
- Simple embellished operators ❌
Advanced Style ✅

According to Google engineers from the Rendering Core Team, a few LayoutNG features necessary to implement MathML Core completely won’t be ready very soon (more details below).

Igalia has a CL pending for mtable which still requires refinement to pass the test for alignment within cells. However, as said in previous announcements, this was pending on the new table support to be available. Currently, this new implementation is still being experimented by Google engineers with the flag flipping on and off recently. They seem positive it will be ready this year though. Once it gets stable enough, work on improving math tables can be restarted.

Regarding stretchy operators, a critical aspect is to ensure that the min-content and max-content inline sizes are calculated as described in MathML Core, otherwise a lot of gaps will appear in formulas. This concern was already raised when upstreaming started in fall 2019. From recent chats, the idea of better min/max pass for LayoutNG is relatively complicated, it will take time and resources from Google engineers and is not going to start before Q4 2021. However, in the meantime, we believe that a more rudimentary support for stretchy operators can be implemented.

Another important task that must be addressed before sending an intent-to-ship is related to accessibility. This was discussed with Google’s accessibility team in 2019 but not much progress was made, again due to other tasks of higher priority and some pending issues in MathML (such as text-transform changing string length or mtable support). Still, first experiments for ATK started and an initial MathML AAM draft was published.

There are additional features that would be helpful (though perhaps not strictly required) to implement before an intent-to-ship as well, such as font-related features (ink metrics, italics correction, font-family: math, etc) or improving interoperability (more conformance tests, refinements in specification, development in WebKit and Firefox). None are really a requirement for shipping, but they will be considered depending on available resources and progress on other tasks mentioned in the above paragraphs.

As usual, updates will be published on this blog when new milestones are reached. Stay tuned!

Q3 review of Chromium's MathML upstreaming

Mon, 07 Sep 2020 00:00:00 +0200

Evolution of upstream MathML rendering during 2020

Since the previous update, Igalia has continued MathML collaboration with Google engineers from the Rendering Core Team. Let’s review again the upstreaming status of the 2019 implementation work:

Basic setup ✅
This step was already done, although we have been working on a few improvements to how token and unknown elements are handled.
Basic Layout ●
The <mmultiscripts> (multiple pre and post scripts) and <mpadded> elements (tweaking spacing) have been implemented. The only thing missing here is the basic implementation for MathML tabular elements, which has not started yet, we will consider it again in one or two months, depending on how fast patches for TableNG land.
Operator Dictionary ✅
We have implemented the low-level API to access the operator dictionary and parse operator attributes (form, boolean properties and spacing). Currently accent and accentunder attributes on underover scripts as well as largeop, stretchy and movablelimits attributes on the underover base are considered. The lspace and rspace attributes are now considered for formula spacing.
Stretchy operators ●
This was pending on the previous step and is now unblocked, we plan to start this important feature very soon!
Advanced Style ✅
As previously said, this is essentially done. We hope to discuss MathML Core related CSS properties this month with the CSSWG. Although this was not in the 2019 plan we also implemented new style for TeX’s “cramped superscript”.

Among things that were not necessarily explicit in the initial roadmap but are still in our TODO list, one can mention MathMLUnknownElement, mixing with SVG or ink metrics (tighter bound for text) or italic correction. Stay tuned for more updates!

Igalia interview with Rick Byers and Rossen Atanassov

Wed, 15 Jul 2020 00:00:00 +0200

Below is the part of the discussion related to MathML in Chromium. You can also read the transcription of the full chat:

More MathML patches upstreamed to Chromium in 2020 !

Mon, 29 Jun 2020 00:00:00 +0200

Evolution of upstream MathML rendering during the first half of 2020

Since the beginning of the year, Igalia has worked with Google engineers from the Rendering Core Team to upstream and improve the MathML implementation we worked on in 2019. Let’s review the status with respect to the 2019 implementation roadmap:

Basic setup ✅
This part is done. Note that compared to the original plan, all unknown MathML Core elements behave like a grouping <mrow> element as agreed in the MathML Refresh Community Group.
Basic Layout ●
Fractions and simple scripts have been upstreamed. A patch for multiple pre and post scripts has been uploaded and mpadded should come soon too. Regarding math tables, Aleks Totic has done excellent progress on the new TableNG implementation. We expect we will be able to update our downstream branch to switch from the legacy table support to this new implementation so that we can then upstream table support.
Operator Dictionary ❌
Upstreaming for this has not started at all, so expect bugs and missing features with operator spacing, stretching, size, etc. We have worked with the MathML Refresh Community Group to provide a compact form for the MathML operator dictionary in order to avoid the binary size increase and make patches acceptable. Refactoring our downstream implementation accordingly will be straightforward and we can then starting upstreaming this part.
Stretchy operators ●
The basic low-level font shaping and measuring logic has been upstreamed and is used to draw radical symbols. The rest depends on the previous step but a lot of the logic in the layout and painting code has already been upstreamed in order to support radicals.
Advanced Style ✅
This step is essentially done. However, it involves new CSS properties to be discussed with the CSS Working Group so the patch for advanced mathvariant has been put on hold and we expect a few extra refactoring and cleanup patches (e.g. renaming) when we get the feedback from the CSS Working Group.

In addition to the above, some features that were not in the initial roadmap have been discussed in the MathML Refresh Community Group and are implemented or being considered. This includes better DOM API, mixing with SVG/HTML, ink metrics (tighter bound for text), new style for TeX’s “cramped superscript” concept and more. Let’s check again the status at the end of the year !

42 MathML Patches Upstreamed

Thu, 23 Apr 2020 00:00:00 +0200

Since our last update in February, Igalia has upstreamed MathML patches to Chromium at a good pace: already 42 patches! Thanks to very helpful review from Google’s rendering core team, we have been able to refine our implementation both for upstreamed patches and for our downstream branch. Here are some highlights of what has landed:

MathML integration with DOM/IDL and CSS.
The low-level OpenType MATH support (layout parameters and shaping of stretchy operators) is completely upstreamed and will be used by the MathML layout for radicals and operators.
Experimental CSS properties corresponding to TeX’s concepts of displaystyle and cramped are implemented. We are currently working on extending the font-size and text-transform properties to implement scriptlevel and mathvariant changes.
Basic layout is implemented for grouping, spacing, fractions and scripts (<mrow>-like elements, <mspace>, <mfrac>, <msub>, <msup>, <msubsup>, <munder>, <mover>, <munderover>).

Although this is still work in progress, one can already notice some improvements. For example, the LaTeX formula \sum_{n=1}^{+\infty} \frac{1}{n^4} = \frac{\pi^4}{90} converted to MathML is rendered by your browser as

$\sum_{n = 1}^{+ ∞} \frac{1}{n^{4}} = \frac{π^{4}}{90}$

In Chromium upstream (Canary, experimental web features enabled) and in our downstream branch, it currently looks like this:

A mathematical formula rendered by Chromium (left: upstream, right: downstream)

We would like to thank all the people who have written encouragements and supported this work, including our fellow Igalians who have helped invest funding. If, like them, you believe in this project and the broader work that we do please consider becoming a sponsor. You can reach us with comments or questions via [email protected]">email or Twitter.

MathML in Chromium Upstreaming Progress

Wed, 19 Feb 2020 00:00:00 +0100

Last year Igalia completed initial prototype work in Chromium of a functional MathML-Core in our downstream fork. By the end of last year we began the work of upstreaming and further discussion and review which we expected to take about a year.

Since then, we have continued to make good progress: Sending patches, discussing and iterating based on input and feedback. As one would expect, things have to happen in some kind of order, and some steps involve more complexity or discussion than others. Here’s what’s happened so far…

We have thusfar upstreamed, in the following order:

Enabling MathML as an experimental web platform feature, and enabling it to run against WPT.
Patching the DOM IDL, making MathML a first class citizen of the Web platform.
Providing the default UA stylesheet for MathML-Core elements
Providing relevant MathML global attributes mappings to CSS counterparts
Adding initial support for the new internal CSS display values for math and inline-math.
Adding basic support for containers: <math> and <mrow>, and then out-of-flow elements in MathML containers.
Adding initial layout contraints for stretchy operators.
Adding support for <mspace>, which is critically used on nearly all MathML WPT tests.
Adding baseline adjustment logic for MathML containers.
Beginning to add support for OpenType MATH layout constants.

Next up, we are working on <mfrac> and continuing the work on stretchy operators (a big step).

Getting initial foundations established, aligned with the platform and landed successfully is important and notable for everyone…

And critically we aren't the only folks doing work in this area.

Our friends at Igalia are implementing MathML and actually specifying what the rendering model and *much* tighter integration with CSS.

(e.g. width/height etc actually work consistently on MathML elements \o/ )
— Ian Kilpatrick (@bfgeek) February 12, 2020

We are excited that each of these patches to land builds increasing and observable value toward our larger goals.

If you’re interested in tracking this more directly, day to day progress is visible via the issue tracking MathML support in Chromium.

If you believe in this work, please considering sponsoring: Your support is important in helping us fund the development and prioritization efforts to ensure that native mathematical rendering is, finally, a universally supported and interoperable foundation of the Web Platform.

MathML Conference 2020

Mon, 20 Jan 2020 00:00:00 +0100

Igalia will be hosting the Web Engines Hackfest 2020 in A Coruña, Galicia, Spain, Monday, May 18th to Wednesday, May 20th. Members from all parts of the web platform community are invited to attend. We are excited to announce that this year we will also include a track specific to MathML. This track will discuss the accomplishments, current status, future plans and fundraising efforts of the MathML project. People interested in MathML are invited to join us please visit the wiki page of the event for detailed information.

Igalia Chats with Neil Soiffer on MathML

Tue, 03 Dec 2019 00:00:00 +0100

Transcription

Brian: Ok, so, I am Brian Kardell. I am from Igalia, where I am a developer advocate. We thought it would be fun and interesting for posterity to do some interviews around our MathML efforts. So, I’m here with Neil who is the chair of the MathML Refresh Community Group and we’re going to have a conversation about MathML. So Neil, I think a lot of people coming to MathML and hearing about it — a lot of them are probably new to it, and they probably don’t realize that conversations about Math on the web go way back. And, I know that you have been here for really a lot of it, can you tell us a little about that — your history, and the history of Math on the Web?

Neil: Yeah, I was part of it from way back from the start — back in the 90’s even. I worked for Wolfram Research and we were interested in promoting a web standard. There had been some initial work on an inital standard that hadn’t gone anywhere. It was very minimal. So, we proposed something to the W3C — and that we should start a group. They were very favorable to that idea so we convened a number of people. We had a few conferences and workshops together. It took a while, but in… 1998, I think it was, we became the second XML application out there on the web. So, it goes back quite a ways. So that was a long time ago, and I was part of that, and I’ve been part of the community working on MathML ever since. Which makes me feel kind of old.

Brian: [chuckles] Yeah. I think a lot of web standards have a long history, but the late 90’s, that really puts it into perspective. I guess it’s historically been kind of a roller coaster ride?

Neil: [slight sigh] Yeah. There have been all of these periods of enthusiasm, and then that gets damped down. And then it comes back up again. You know, we had this proposal, it was 1998, and that was great. It was a compromise, as most standards are, and it was huge because of that compromise. That was maybe a problem because that made it harder to implement. Another thing was, as I said, it was an XML application — so we had hitched our wagon to that, but that did not turn out to be the direction the web went in. On the other hand, so did SVG, and SVG has had a little more buy-in on the web than MathML has.

Brian: Yeah, I’m glad you mention SVG, because I think there are two really interesting things about this. One is that both MathML and SVG are specifically integrated into the HTML parser later on and so they’re “special” in history. But also, like with SVG, because of that aspect of it — MathML has this huge ecosystem around it outside of browsers: From things to understand and transcribe it from handwriting analysis and pictures and just, all this cool stuff… But browsers, I think, have been really where the rollercoaster ride has been, right?

Neil: That’s right, yeah. It’s been a little strange that all of the browser implementation work has been done by volunteers — it was never initially picked up by the browser vendors themselves. I’m not sure why. I could guess that maybe there is some Math phobia — or maybe math wasn’t the sexy thing to work on or something… I don’t think anyone ever said “gee this is a terrible standard and we don’t want to do it” it just never seemed to become a priority for them. That’s been a disappointment. We’ve seen ups and downs, and I can get into that, but yeah — it’s used in so many places as you indicated. It’s used a lot in publishing because they really do like XML workflows in publishing. But, on the web, it just hasn’t been able to get into all the browsers in the same way other things have. It has been supported in several browsers over the years, but yeah… right now, it is making a comeback — and the roller coaster is on a big upswing, I think.

Brian: Yeah… Sort of my favorite bit of history here is that MathML has been really the victim of just so much unfortunate timing. So many things that have little to do with MathML itself, but about changes. For example, which browsers were popular at the time, which ones you had to get into — and then also, as you said, the shift from XML and XHTML looking like they are going to be the future and then it leaves W3C and goes into WHATWG as HTML, eventually integrated into the parser. There’s just a really bunch of interesting things there about the unfortunate timing.

Neil: Yeah, well, you’ve jumped through probably two decades worth of time there, but … yeah. Initially, way back around 2000, it’s probably hard for people to remember even, but the browser back then was IE. Maybe it was IE6 at that point — and — Design Science, a company I eventually joined, produced a plugin for IE called MathPlayer. It supported MathML, it was great. Firefox was a really small percentage, but it was a percentage and people wanted cross platform support. They got MathML support, but when they did it was for XHTML documents only. I can’t recall the reasons why, but, as you said, that seemed to be the trend back then that maybe XML was the way things would go. Turned out, not at all. This created this incompatibility because IE then did not support XHTML. So, we ended up hacking the IE plugin so that it would transform XHTML to HTML, and that was all very good. We were all very positive at Design Science that we had solved this problem — because, now all you had to do is put out XHTML documents. But… there wasn’t an easy way to do that. Most people were putting out HTML. So there was confusion about this, and this lasted until about 2010, I guess, when Firefox finally supported it as HTML. But, by that point IE was falling away, and they had stopped supporting the interface that MathPlayer needed in order to work — and now Chrome was getting to be really popular. So, a volunteer worked and, had some pretty good success, getting an implementation into Chrome [through webkit]. And so, at that point — I think we were up to 4 browsers supporting MathML in some form or other, and things were looking positive, and I think there was a lot of excitement that Chrome was finally going to get it — it was the dominant browser. But, unfortunately when there was a fork to blink off of it, they yanked it all out. There were issues, maybe with security. But in the end, that was a kind of a downside turn for MathML in browsers because this dominant browser no longer supported it. The support in IE had kind of failed as IE went away. It was a bleaker period for MathML support. There were a lot of people who were very upset about Chrome support being yanked. It is ranked as the third, or maybe even the second issue that is sitting there in the Chrome logs as people wanting it back. There definitely were people saying great things about MathML, but it just wasn’t clear why it wasn’t getting the attention from implementers.

Brian: There was a little bit of a double whammy here, actually, as well. Right about at, approximately at the same time that the math support was removed… and… oh… actually, when we say the math support was removed, we should say math rendering support, more correctly because the parser in all of the browsers still parses MathML specially because…

Neil: Yeah, that’s something that I think is really important. MathML did go into HTML5, but HTML5 basically defined how the parser was going to turn it into the DOM — it didn’t say anything about how you must render this.

Brian: Right. It just delegated that support to supporting the rendering of embedded MathML. But, the other sort of double whammy… or, maybe this is the triple whammy, or quadruple whammy? But, it’s right about the same time that support was removed — or — maybe just before, a thing that I was involved in — the Extensible Web Manifesto was published. And, the thing is — it argues how we move forward, and it distinguishes between existing high level features that make up the platform, and new features. And, I think this actually played out pretty badly for MathML too because, like, which one is it? Because we lost support…

Neil: Yeah, I agree, you are kind of stuck in this limbo where you’re not really supposed to add it because it’s in there, and yet, it’s not supported, so you need to add it on. It’s a catch 22.

Brian: Yeah, it created a difficult situation because of the split with blink because not just chrome, but opera followed — and so in a very short period of time — like, maybe a week — the trend for MathML seemed to turn increasingly bleak…. But… well… here you are again, with us, and the MathML Core specification, in the MathML Refresh Community Group, chairing it. And, well, I just want to give you the opportunity to answer this, because I know a whole lot of people have asked me as I talk to them about MathML “…ummm…well… [sigh]… is it going to be any different this time”?

Neil: Yeah, sure. Well, as bleak as it looked in the browsers, it actually had a lot of buyin from publishers and in the accessibility community because that is what the screen readers could use. That is what the dyslexia tools, which wanted to do highlighting of math — that’s what they interpreted. So, there was a lot of non-browser based support for MathML out there — and that support all still exists, and there are still a lot of people who really want to see MathML supported natively. So, while MathML itself wasn’t natively supported in all of the browsers, there is a wonderful — and very large — library called MathJAX. It’s a JavaScript library that does support MathML. It also supports TeX. So, there’s a lot of Math out there and the nice thing about MathJAX is that it can hide the MathML (since it can’t be displayed in Chrome) but they hide it in a way that screen readers can still see it. Wikipedia does the same thing, Khan Academy did the same thing, and, in fact… I was just helping my son with a calculus problem and needed to refresh my memory about how something worked, and I was looking at a bunch of web pages, and they almost all used MathJAX or hid it the same way because they did some server rendering — but they’re all accessible because they have the MathML. So, it’s there, it’s just not being layed out in the browsers. And, as wonderful as the MathJAX library is, its a JavaScript library — and there are just problems with JavaScript libraries beyond just load time, interacting with other things. So, I’m maybe losing the initial train of thought, but I think that this time around, the Igalia work is pushing it foward so that the rendering part of it can show up, and the MathML that’s been there all along can just be put in to be rendered. So, the support that Igalia has given to the implementation and the support that the Chrome team has given Igalia, all makes me very excited about the future. Oh, and also the work the Igalia team has done to help make the other browser engines consistent with this newer work that the refresh community is doing. It just has all of the signs that I think this time, we really have it.

Brian: I agree with…I agree with the .. the idea that this time is gonna be different. Because, not just we have the support and the implementers and the sort of good working relationship — but because the MathML Refresh Community Group, which you chair, took the time and actually answered all of the questions and concern that were lacking. Because of this weird history, there was this big gap. MathML, even in the browsers where it was implemented, it was kind of… undefined how it would work in the browsers.

Neil: Yeah… a little defense of MathML, but also, a strong defense of what the group is doing now: Way back in 1998, when people wrote specs, the idea was that browsers would do the innovation and they didn’t want specs that forced everybody to do exactly the same thing because there was a lot of innovation coming on. So if you put out a web page, it wouldn’t on the same on one browser… exactly the same, on another. And that was, I think, a goal back then because people wanted to see — you know — what’s the best way to do things. And, that’s changed dramatically. Now we think “if I put out a web page it should look the same everywhere” and the goal of the refresh group is to do that same thing for MathML. So, one of the things we’re doing in MathML Core work, the part that goes into a browser, is we are looking at how MathML integrates with CSS, and defining layout in terms of the CSS Layout Engines so that the MathML will layout identically in every browser. We’re paring out the parts that are problematic or aren’t used very much, letting those be handled for now by a polyfill to maintain backward compatibility. The issue that made it difficult to implement MathML in a browser, we’ve looked at those and we’ve tried to make that not a problem, and get everything to be identical everywhere so that MathMl fits the way the Web works nowadays.

Brian: Yeah, definitely. And also, I wanted to make sure you understood the context of my point, because it was not in any way to say something negative about MathML. It’s that it comes from a co-evolutionary past. It was evolving at the same time as HTML and the DOM and how we think about and write up standards. Like, do we write them up in this way where there is infinite room for browsers to interpret them in many ways? Like, do we write the words first without worrying about the implementability of it. Because of this, the spec was not very inline with today’s web platform, and I think that the work that the MathML Refresh CG group has done to integrate it with CSS and the way that we think about units and the roles of attributes and DOM nodes and the DOM itself, actually, is my favorite one… And how we look forward to the future together and integrate with it all together. In fact, one of the things that makes me very very positive is, as you say we have had some positive support from Google and patches have begun landing upstream in the past couple of weeks.

Neil: Yeah, one of the things that I’m very enthusiastic about is that years ago, when the volunteer that I mentioned trie to put MathML into Chrome — he told me that it was like pulling teeth to get anyone to do a review of his code. And now, these pathces that are landing, I’ve seen very quick response — people are very excited to see these come in. They have comments about how to do some things better, but the interest is there, and I think that’s a world of difference from before and that makes me very, very this time around.

Brian: So… Another thing that I wanted to ask about — and you have actually answered it a little bit already… When I talk to people about this, they point to — as you already said — the fact that there is a lot of MathML on the web today — or — there is a lot of math on the web today, even more… A superset of MathML I guess. So, it is there. It exists. You can see it. So, kind of, what’s the problem? Why does it really matter to have native support — instead of just some amazing tooling that can turn it into SVGs or images or something like that?

Neil: Yeah. So.. Again, it comes down to this issue of standards. Once people have standards, they can innovate more because they don’t have to reinvent the wheel every time. There are a number of math editors out there that have their own implementations to draw the math. Except for the very big ones like MathJAX, they tend to have a number of rendering issues when you start stretching things like parenthesis, you might see gaps in them, or they might not stretch very well at all. They may look really funny. And, there are other issue — like if you want to start building interaction, you don’t have a standard underneath to draw — what one person uses underneath can’t be used by someone else, because they render it a little differently using divs and spans and playing different tricks. Once you have that standardization, you have, essentially the ability to stand on the shoulders of others and… stuff happens much better. So, whereas you might see some very nice work — like: Desmos has some very nice interactive stuff — it’s just Desmos only. I can’t export it for someone else and do much of anything other that they support export and import from MathML, but I’m not able to use their interactivity in any particular way. So, I see the standardization as allowing all sorts of innovation to really take off as opposed to being one shot efforts that can’t integrate with each other and can’t build on each other.

Brian: I think there’s also a really strong case to be made here that math is text, and text is sort of the web’s thing and putting text into images and things is not..Well, it seems very weird trying to think about how you manipulate the rendering of text itself with JavaScript without some other like really core fundamental primitives that are currently not there. It feels bad, right? And it feels worse to me even that this is sort of almost discriminates against this one particular kind of text which is fundamentally important to STEM the origins of the web and I think, society. I think there’s sort of a like a [argument about] what should the web be and do, for I don’t know, ethical reasons — I suppose is maybe the thing I’m trying to say here what do you think?

Neil: Yeah. I mean, you know there’s… you could do look at all these studies that talk about STEM being important for people to get good jobs to understand the world better . There’s, you know… There’s lots of things about STEM and when it becomes harder for education to put out math on the web that’s just a blockage for people to learn it and become more proficient in it and it does seem like a disservice to a core part of, I mean not — you know not just math but it’s it’s science and engineering and medicine and all sorts of areas that it’s just harder to collaborate in because there’s no easy way to put the math out. Or, you know, there’s no way to build upon these things. So, yeah, it it’s always bothered me. I’ve had a phrase that every kid and from kindergarten through 12th grade has to take a math class and whereas everybody uses the web these days for regular text. math has been a kind of backward area. Maybe four years ago now Wikipedia finally buried the MathML inside of the math that it generated [for rendering] so it was at least except accessible but it’s still not as rendered as nicely as the regular text in Wikipedia and there’s just no — you know — rationale for why math should be held back that way.

Brian: Yeah I think I think basically we make it hard, and we make you think about… well, make you think about things that you don’t generally have to think about for text like flash of unstyled content, like dragging down the performance of your page, like potential failures in which you get something that is like — gibberish on your screen. So I think that is really interesting. You hit on, in your earlier statement — just now and a little bit before too, about how a standard lets you stand atop that and do interesting new things.. So, I’m curious – like do you have any particular hopes for what kinds of things a universal standard highly interoperable math on the web would have

Neil: I think there’s a lot of possibilities for interactivity. So, people have written some editors for the most part they’re not as powerful as they could be if they didn’t have to spend so much effort trying to figure out how to get the rendering done. I think they could spend more effort on the interactivity. There are people that have done, you know, great things. I mentioned desmos. There were nice graphics nice interactivity and stuff but it’s it’s a world unto itself because they’re not building upon each others back, and so that desmos application: I can’t just pop it in to something else it’s it’s there it’s by itself and that’s the way it is and that’s unfortunate. There’s a ecosystem called Jupiter notebooks which is a sort of Python an in the web and that has become very popular. math I think still remains a bit of a problem there because again MathML’s not really there. The nice thing about Jupiter notebooks is I have the data there. I have programmability. I can produce graphs. I can peruse tables. I can manipulate the data in various ways and send it off to my colleagues and they look at it and they have that data there and they can do their own thing. But you can’t do that really with the math because if I ever wanted to do something with the math — I’ve kind of got to pull it out to its own little application, because it’s not a standard that’s really supported everywhere. So it’s to to look at some of these isolated things and say yeah well if I could just put them all together then I have this really neat little thing that I could start doing. And maybe I could, you know, take my handwriting and pump it over here and I don’t have to type and do that. And then I take it out there and I manipulate it again by doing a little bit more handwriting and crossing things out and so forth as I would do on a pencil and paper. You just can’t do that where everybody has to implement their own version of how to lay the math out and there’s just no standard that people can depend upon that works across all the browsers. So, there’s you know, once you start thinking about the interactivity you can start thinking about what about , in education, what kind of neat interactivity things can I do and there. There are some specialized programs that use their own specialized tools to do that but again they don’t build upon each other and it’s it’s such a sad state that everybody has to go and reinvent the wheel every time they want to do something with math. So, I’m very excited at once MathML support gets in there we’re gonna see all sorts of really interesting applications come up because people will be able to take advantage of what’s there and what clever things one person has done and incorporate that in math to the work that they’re doing, and not have to reinvent that part of it.

Brian: Yeah I think actually, for me, one of the things that’s really interesting about the things that you said there is MathJAX itself. Because… I think people hear us talk about wanting a native standard and why maybe MathJAX isn’t like the right final answer for this problem and they get the impression that we think MathJAX is good.. or, I mean, is bad. Personally, I think MathJAX is good because it’s enabled all these things…

Neil: Yeah, I… You know: I want to I want to say absolutely I think MathJAX is wonderful it allowed math to show up on the web and the people that have done it have done a great job with the rendering and I am 100% behind them. It’s just they had to spend a lot of effort on things that they really didn’t shouldn’t have had to spend.

Brian yeah, yeah — no this this is exactly going to the point that you were saying that I was trying to pull back into which was: MathJAX actually does like… they have explored considerably more than simply the rendering part, right? Yeah and, so really, I think a lot of the work that we’ve done in MathML core is to help enable them to continue to do that — but just not worry about the rendering. Because, there seems like a lot of the people who were involved with mathjax are now working with, like my coworker Joanie — the editor of ARIA, with you. Like, how can we make MathML exploration interactive and like, more accessible and explorable? And, I think there’s like lots of great things that they can do if they can stand on top of a standard where a whole bunch of the problems that a lot of us see with the current state of things are just resolved, right? Like that the library gets smaller, and you don’t have these like worries about like: When does your page render text and reflow and how much JavaScript you have to load to just see the thing? I just think all that gets a lot better if we give them a really good foundational core on which to build

Neil: Yeah, I mean one of the things I mentioned I mentioned before as I’ve been involved in accessibility and accessibility is a really big deal using math and now and way back in mathplayer I added the ability to synchronize the speech and highlighting because for people with dyslexia it’s been shown that if you highlight a word it helps focus them as you speak it so that they can read the math better and there’s studies that show that actually math reading is twice as hard or they make twice the number of errors that they do in reading regular text and without a standard for how do I pick out the part that I’m going to highlight that synchronized highlighting has kind of been lost for the last decade because math player’s no longer doing the rendering. I think once MathML gets to be back as the standard way of displaying things we’ll get back to being able is for it something as basic as highlighting the math as it’s been just as it’s done for text now by the various tools that help people with dyslexia.

Brian: Yeah I think I think all this is really really great I think one of the things that’s like… probably hard for a lot of people to appreciate - it certainly was difficult for me to appreciate before getting involved with standards — and even the MathML work, is just how difficult text rendering actually is. And to do it in line with the browser in the way that the browser thinks about it and flows it and when it processes and participate in all of the rules and everything… I was talking to a friend here in Pittsburgh who is very well-known for design and the two of us were just thinking about how recently it seems we’ve gotten a lot more information about just how difficult the rendering of text is, and how magical we’ve made it. And also how that that is such a nice thing — that you don’t have to think about just how much complexity is there yeah.

Neil: I mean, I completely agree. It’s taken for granted I think. Most people think you just are, like, well I guess just laying out some text maybe. There’s bold maybe, there’s italic, it’s just gonna wrap around the lines… I mean how hard is this? But in fact making it look nice and, you know, at the very lowest level having a nice looking font that’s gonna render cleanly on various displays of different resolutions and be clear… that’s incredibly hard stuff. And, to me, the layout of math is so much easier than that. People have put in so much work to make text look nice on a screen [for non-math] — it just pails in the amount of time the in on doing that then what it’s taken to do the math stuff and we all take the text for granted. I think people think “Oh laying out the math is so hard” but once you have a font that you know can do the type of things math needs to do and that includes being able to stretch things like parentheses and other characters — arrows and whatnot — once you have that the math layout is relatively quite simple to sit on top of all that work that other people who have done.

Brian: Yeah I’m I’m really excited to see to see all this stuff land and to also — like, imagine the larger impact on society in like a long time. I think that this has like good good potential for a lot of positive things like you mentioned Jupiter notebooks and things like that that are exploring I think it would be fantastic if… well not “it would be” — it will be fantastic when the web is able to finally meet — 30 years since its inception at CERN, be able to really meet the use cases that they had at CERN at the time.

Neil: Yeah you know when you think back to where it all started as you said back at CERN and you know this is a scientific thing. Tim Berners-Lee was a physicist he wanted to put out his stuff and that still remains a little bit problematic how he can do that, and that’s a little strange. But, I’m really really excited that that problem after, as you said 30 years, is going away - and to see to make it so easy that people can do their research. It’s a great thing and I’m really happy to be part of pushing that forward and I’m really glad you’re part of that effort too because you’ve great help also.

Brian: Thank you and thanks for spending the time to talk to me. I think this was a fun chat that we had and hopefully people find it interesting.

Neil: Well thanks for inviting me to do the chat hopefully some people learned a little bit about the history of MathML and why it’s gone up and down in the past and why this time it’s finally going to catch on

Brian: Yeah. Excellent. Thanks Neil.

Neil: All right, thanks

Brian: Bye bye

Neil: Bye

MathML in Chromium: Upstream process started

Thu, 31 Oct 2019 00:00:00 +0100

The Chromium project has a very important process for launching new features. MathML is a well-established standard implemented in two other web engines (Safari and Firefox) and frequently requested by users of Chrome and Microsoft Edge, but it also has a complex history in browsers. As a consequence, it was necessary to proceed a bit differently than other new web platform proposals.

From the beginning, Igalia engineers have gathered feedback from the community by participating in the MathML Refresh Community Group and talking to browser implementers and other standardization groups in order to reach a consensus on what eventually became MathML Core.

In parallel, they have been working on a Chromium branch in order to obtain concrete results for discussions with Google engineers and the web community in general, for the MathML Core specification and for Chromium’s design documentation.

Finally, they have contributed to the inter-operability effort by creating a test suite of about 2000 subcases and making necessary changes to existing browser implementations.

After all of this, there is a solid proposal with a wide consensus on MathML Core. The “Idea” and “Design” phases of the launch process are complete and a significant portion of the “Implementation” phase is ready. The upstream process can start!

MathML and Browsers

Wed, 28 Aug 2019 00:00:00 +0200

Users can easily get confused between the different browsers, web engines and MathML statuses. This blog post provides an overview and summary in order to clarify things. For each MathML implementation, a screenshot of the same formula involving the Gamma Function is provided so that one can easily compare their rendering quality. Here is what it looks like in LaTeX:

A mathematical formula rendered by XeLaTeX

The rendering engine is one (primary) component of a browser. Rendering web content is very complex business, so there are only a few. Today, the three rendering engines are: WebKit, Blink and Gecko. Each of these is open source, and can be used in several browsers. Along the way, however, there have been some other notable ones: Presto, Trident and EdgeHTML. Each of these was proprietary. Each has (or had) markedly different architectures and evolutions.

The WebKit rendering engine is used by several browsers, notably: Apple’s Safari browser or GNOME Web. An initial implementation of MathML in WebKit happened around 2010 and was later improved in 2012. Back then, Google Chrome was also using WebKit and MathML was enabled in Chrome 24. Here is how it rendered:

MathML in WebKit-based Chrome 23.0.1271.99 for macOS (2012)

A few months later, Google announced a fork of WebKit, which they would re-factor into a new web engine called Blink. Blink is used for the Chromium browser. Chromium is really the same as Google Chrome modulo minor differences. During this refactoring, MathML was disabled and Blink has remained without support ever since. The latest version of Chromium does not support MathML rendering, so basically it renders text without any math layout:

MathML in Blink-based Chrome 76.0.3809.100 for Linux (2019)

This is, more or less, how Microsoft’s Trident and EdgeHTML engines would have rendered as well.

Older versions of Opera used the proprietary Presto engine which supported the MathML for CSS Profile (effectively just default User Agent styles). This would have rendered very much like this:

MathML in Chrome 76.0.3809.100 for Linux (2019), with Presto's extra CSS rules applied

However, today, many browser projects are based on Blink/Chromium, including both Opera and, more recently, Microsoft’s Edge.

During the first semester of 2016, Igalia engineers worked on a complete refactoring of the MathML code in Webkit to address main design and rendering issues. This is more or less the implementation in recent releases of WebKit, and it renders like this:

MathML in WebKitGTK 2.24.3 for Linux (2019)

As part of the MathML in Chromium project, Igalia has also been implementing MathML on top of a new layout system for Blink currently being developed by Google. In Igalia’s Chromium build, MathML is currently rendered like this:

MathML Chromium 78.0.3874.0 for Linux (Igalia's development build)

Finally, Gecko is another web engine which is best known for being used by Mozilla Firefox. The Mozilla MathML project started 20 years ago and support was released in Mozilla’s 1.0, two years before Firefox 1.0 was actually released. MathML is still supported in the latest versions of Firefox:

MathML in Firefox 68.0.1 for Linux (2019)

Although the history of browsers and native MathML implementations is a bit complicated, the summary is:

Old implementations from Chrome 24 (WebKit) or Opera 9.5 (Presto) no longer exist and have nothing to do with newest implementations.
All modern browsers are essentially using or going to use one of the three open source engines: WebKit, Gecko and Blink. MathML is implemented in the first two and is being implemented in the last one.
These are really three different MathML implementations but work is in process to improve interoperatility between them and fix bugs.

MathML in Chromium: Project status after one semester

Thu, 25 Jul 2019 00:00:00 +0200

Evolution of MathML rendering during the project

Let’s review again the status of the initial implementation roadmap with details of the subtasks for the fundamental Stretchy Operators section:

Basic setup ✅
Basic Layout ✅
Operator Dictionary ✅
Stretchy Operators.
1. Shaping large and stretchy operators using the MathVariants table ● Support has been imported from WebKit and is doing the job for now. However, the plan is to better integrate it into Chromium’s text layout code and to implement the full support described in MathML core.
2. Drawing of largeop operators ✅
3. Stretch logic in mrow-like elements and under and over scripts ● Experimental support has landed and operators can now stretch but this still need some more testing and polishing.
4. Using stretchy and symmetric attributes ✅
5. Simple embellished operators ● Very partial support has landed.
6. Roots (msqrt, mroot) ✅
Advanced Style ✅

Screenshot of the <x-tex> Custom Element demo in Igalia's Chromium build.

Besides the implementation effort, Igalia has been collaborating with the W3C MathML Refresh Community Group on the MathML Core specification. The group continues to improve MathML compatibility with CSS and HTML5. More web platform tests are being written in order to ensure better interoperability in all implementations!

MathML in Chromium: Igalia is making good progress!

Fri, 03 May 2019 00:00:00 +0200

Last month, Igalia developers attended BlinkOn. It was an opportunity to introduce the project to the Chromium community and to present the first MathML results after three months. Things are progressing well as you can see on this slide show which demonstrates the improvements in rendering on two mathematical formulas over these past few months:

Evolution of MathML rendering in Chromium

Currently, the status on the implementation roadmap is as follows:

Basic setup: This part is complete. It is possible to display equations (centered in its own paragraph) and inline equations (with correct alignment with respect to surrounding text). Support for miscellaneous mrow-like containers, text or spacing elements is implemented. Finally, basic style attributes (direction, colors, font-size) are mapped to CSS.
Basic Layout: This part is complete too. This includes fractions, various scripted elements, simple table layout (e.g. for matrices) and more advanced spacing.
Operator Dictionary. This part is still in progress. For now, simple dictionary-based operator spacing is implemented. More features like accent, largeop or movablelimits are expected.
Stretchy Operators. This has not started yet and is currently the most obvious missing features (e.g. big integrals or stretchy fences). Discussions that happened with Google at BlinkOn will help to start the implementation soon.
Advanced Style. Support for the mathvariant attribute (including automatic math italic for variables) has been implemented by extending the text-transform CSS property. A new CSS property for displaystyle is also available but it is not fully used yet in the MathML layout. Support for the scriptlevel attribute is missing but thanks to the help of Mozilla, the MathML Refresh Community Group has designed a CSS proposal that will be used to implement it.

Besides the implementation effort, interoperability work mentioned in the initial announcement is also being pursued at a good pace. Stay tuned for more updates!

BlinkOn 10

Mon, 08 Apr 2019 00:00:00 +0200

This week, Igalia will attend BlinkOn 10, the main event for Chromium developers. Rob Buis and Frédéric Wang will present the ongoing MathML project and the current status (specification effort, WPT tests, LayoutNG design, demo of prototype implementation…). If you plan to be in attendance and would like to have a quick chat, please reach out to us via info at igalia.com or you can follow us on twitter @igalia.

Launch of the MathML project

Tue, 12 Feb 2019 00:00:00 +0100

Last November, we announced that NISO obtained a grant from the Alfred P. Sloan Foundation to support the implementation of MathML in Chromium. Thanks to NISO’s sponsorship, Igalia’s web platform engineers will be able to commit to MathML development in 2019.

Brief summary of activities to date

Google contacted us early this year to reiterate their support for this MathML project. Their layout team offered to help Igalia with design and code reviews. They also re-confirmed the plan agreed to in 2017 which was that we will work on top of Chromium’s new layout engine “LayoutNG” and introduce C++ API or CSS features as needed to ensure a clean layering.

Development has been in progress since January. Following the approach used for adding Wayland support to Chromium, we set up a dedicated Chromium branch with continuous integration (for style check, compilation and test execution). This branch is regularly rebased against Chromium’s upstream repository in order to get the latest changes to the layout engine and ensure that the web platform tests are up-to-date. Incidentally, these MathML tests are now imported into the Chromium repository at regular intervals.

In 2016, we realized that the official MathML specification and test suites had several limitations. In particular the MathML 3 specification lacks detailed implementation rules for web engines (integration with CSS layout, use of low-level primitives, math rendering based on TeXBook’s appendix G and the OpenType MATH table…), the official MathML test suite is not automated and the specification has many features without strong use cases. Similar concerns have been raised by miscellaneous groups including browser vendors and more recently the W3C TAG.

Some effort has been made to address these issues. Specifically, an implementation note for a core subset has been drafted, we have started the transition from browser-specific and non-automated W3C tests to official Web Platform Tests and a lot of feedback has been provided to the Math Working Group. The Math Working Group has, however, been on hold for a while which has prevented any official progress at the W3C. After discussion between browser implementers, former Math WG members and other actors of MathML community, a MathML Refresh W3C group has been launched to tackle these issues.

Next steps for Igalia and the MathML Refresh W3C Group

One of the main goals will be to work on a new specification for a core subset of MathML with careful implementation details. Some redundant or less important features will be deprecated and tools to ensure backward compatibility will be provided. Missing low-level primitives for math rendering will also be added: for example we’ve been working with some Mozilla engineers to standardize CSS features for math that are currently implemented in Gecko/Stylo as internal properties. Last but not least, great care will taken for better interoperability and more Web Platform Tests will be added to verify the specification. In particular, we expect to import, merge and rewrite tests that are available in WebKit and Gecko’s own test suites.

Conclusion

We believe that we are off to a good start and we are excited to implement MathML in Chromium. We look forward to continuing to collaborate with the different groups on W3C specifications and tests for better interoperability of math on the web!

NISO is sponsoring the implementation of MathML in Chromium

Tue, 27 Nov 2018 00:00:00 +0100

We are very happy to announce that Igalia has just received the confirmation from the National Information Standards Organization (NISO) about the sponsoring for the work related to support MathML in Chromium.

Last August NISO announced that they have received a grant from the Alfred P. Sloan Foundation to support the implementation of MathML in Chromium. With these funds NISO becomes the primary sponsor of this initiative covering the project roadmap defined on this website.

Igalia is really grateful to NISO and Alfred P. Sloan Foundation for trusting us to develop this work. We’re still drafting the final plan but ideally everything should start moving by the end of the year or the beginning of 2019.

We’ll post more updates on this website. Stay tuned!