Moving Math Forward, Thoughts and Experiments
In this piece, I explain details on thoughts on experiments and conversations around moving Math forward on the Web.
For some context, my team is actively working on implementing MathML in Chromium (the engine Chrome, Edge, Samsung, Brave, UC Browser and lots of other share), more specifically MathML Core. MathML has long had implementations in Safari and Firefox and has an intersting history that leaves it in a very unique spot.
MathML Core, defines the comparatively small, but well defined and mostly interoperable subset of MathML - with an aim of resolving uniqueness. It provides details about how it actually fits into the layers platform in well defined ways and to explain their existing magic in terms of the platform - to expose it if is it new. As such, in indirectly aims to provide a basis for moving many things forward.
A thought experiment
Recently conversations in the web platform at large have begun about moving HTML forward and polyfilling elements. Since we are actively working on a 'core' ourselves, we thought this would be an interesting discussion and experiment: We asked "What if MathML Core was largely 'done' and you would import other support to move forward?" Those things could potentially be shipped by a browser, but there's no guarantee they ever would. However, they could also be loaded as polyfills and in standard means that help omit many of the problems that traditional polyfills create.
To explain this, we took some elements that aren't in MathML Core, but are specified elsewhere, as an interesting stand in. One such example is an element called mfenced. mfenced is just a "more convenient way" of writing some math that has a lot of 'fences' (parens, pipes, braces, and so on). The original spec even said "It is strictly equivalent to this expanded, longer form".
Today, 'polyfills' exist for it if your browser doesn't support it, and today, those work by (if your browser doesn't support it) destroying your tree and replacing it with the equivalent version, at some undefined point in time.
We experimentally changed very little in our implementation and it now considers any MathML 'unknown element' as on the whitelist of elements which can have a Shadow DOM. We used a simple stand-in using Mutation Observer to allow any of those to be defined without a dash, and wrote a polyfill for mfenced which simply expands it into Shadow DOM.
For purposes of discussion, we illustrated how we could, in theory, use MathML Core, import some new vocabulary (potentially a future proposal, or just some slang) and easily expand it into some Shadow DOM, leaving you with the tree that you authored and all of the things just fitting together nicely and predictably. Below is a screenshot from our actual implementation experiment.
We think that these sorts of experiments are useful and informative and help us ask better questions about how we are fitting into the platform itself: Have we answered the necessary questions? How does the introduction of a ShadowRoot impact rendering and namespacing, for example? Could developers really 'plug in' to all the necessary bits? Could they properly layer atop? To test this, we also created elements that expand shorthands like TeX and ASCII Math. In the end, can we ultimately resolve a great a stable core that allows us to move math forward using these things similar in ways similar to Knuth's TeX book/engine - but in a way that is properly "of the platform"? We think the answer is yes.
While we're not entirely sure where larger conversations about how HTML will move forward will go, and we aren't claiming that this implementation is anything more than a quick experiment for discussion and testing, the MathML community itself is very excited that such talks are even happening in HTML and very interested in being a part of that conversation, and sorting out how we can move forward together as One Platform™, with less 'specialness'.