One Platform™
Let's talk about making SVG and MathML less special.
As I mentioned in Harold Crick and the Web Platform, the HTML specification contains a section on "Other Embedded Content" which specifically mentions SVG and MathML. In that piece I explained their unique histories - how they wound up being "special" and how I felt this leaves them in a kind of unique place in the platform that deserves some similarly "special" attention in order to resolve.
What I mean by this, in part, is that we need to think about how to make them less special, so that we are reasoning about things as One Platform™ as evenly as possible. I'd like to illustrate and talk about two simple examples:
What is this element?
The HTML parser parses these things specially. While this is a kind of advantage we don't expect to be repeated, it actually came at a cost of historically disadvantaging the actual elements that we had to work with. They lacked basic/general interfaces that are otherwise common among any other element in HTML. There's really no great reason for this and we should unweird it - it's not hard. Last year, this work began by providing a mixin that could be used in SVG, and we'd like to do the same for MathML which lacked any kind of IDL at all.
What does this mean in practice? Well, it means that if you grab a reference to a MathML element, for example, and try to set it's .style property - what happens? It blows up. Why? Because if you ask it what is it's .constructor, the answer is just Element. But you can style it with CSS just fine. Common things like data-* attribute and tab indexes just don't work, trying to access any of over 100 common API properties or methods that Just Work anywhere else will throw, or not function. All of this is unnecessarily weird, for not great reasons.
This is a really basic thing and it's not at all hard to do technically. It seems unlikely that the parser will change, and everyone agrees that MathML is a reasonable thing to send to a browser (whether they believe that it is necessary that the browser itself renders that or not), so I am not sure why this should be controversial. This is a useful normalization of basic, low level platform things. It feels like everyone should support this.
Generally, let's make them both as unspecial as possible - which leads to the other thing...
How do we move forward?
HTML has had, and continues to have, a whole lot of thought and efforts to define "how to move forward". Figuring out the underpinnings of both the platform features necessary and a process enables the Web to really work and flourish is a big effort. A wide range of efforts over the last several years like Custom Elements, Shadow DOM, Houdini, AOM, modules (and types of modules), ways to share stylesheets, Import Maps and built-in modules are all, in some ways proposing elements of possible solutions to the basic question "How do we move forward?" A lot of this takes a long time and advancing frequently requires compromises in the interim.
Recently, new conversations have begun attempting to assemble these into a larger possible vision and discuss resolving compromises made along to really answer this question.
However, currently, SVG and MathML, exist at least partially outside many of those years of conversations and thought. It feels important to at least stop and consider the question: How do these move forward? And, if that doesn't look like the rest of the platform -- why not? Figuring out how to align with HTMLs "forward plans" seems very valuable.
I don't have concrete answers here, but I'd like to start making these things part of the conversation. For example...
Polyfilling Elements, Custom Elements and Built-ins
One of the more interesting recent conversations recently is around moving forward and polyfilling elements. It is, of course, very early. This issue and related efforts are intended to open conversation by offering some larger picture that we can talk about. One interesting conversation, I think, would be to think about how this might relate to SVG and MathML. The topics of Custom Elements and Shadow DOM, for example, are two that are thus far historically outside of SVG and MathML.
One way of looking at it in the thread offers that we might say that HTML itself is largely (not completely) 'done'. Not standards, just the core of HTML itself. It offers that what you could do then is import other support, and that support could also potentially be shipped down natively by the browser or polyfilled.
But, how does this apply to SVG and MathML? Is there real use in asking these questions? We think so.
While we're not entirely sure where larger conversations about how HTML will move forward will go, as part of our efforts to implement MathML Core in Chromium (the engine Chrome, Edge, Samsung, Brave, UC Browser and lots of apps share), we are asking lots of questions about how things fit into the platform more naturally. In this, we've recently done some interesting experimenting with some of these concepts in order to ask potentially useful questions. We believe these are both interesting 'at large', and actually very useful in helpng us make sure we're thinking about all of the right and necessary things.
If you're interested, you can read more on some experiments (with implementation) and discussions around them regarding Shadow DOM, Import Maps and potentially prefix-less custom elements for MathML and how we feel this is both compelling and helpful.
While the MathML Community Group is aware that these questions are far from settled, they were universally excited to see such talks begin in HTML and very interested in making sure that they're thinking about those things too: Being a part of that conversation, and sorting out how we can move forward together as One Platform™, with less 'specialness'.
If you think this is interesting or useful, please share your support and let someone know.