Today I merged a pull request for which introduced the following setup for equation editing, as an alpha feature for our RichText editor: 1. The “status quo” renderer, displaying the mathematics on all “read-mode” article components. 2. A new renderer, specifically loaded in the iframe of our editor widget. Why? Because loading MathJax twice is too slow for our show, but we still want our displayed richtext equations to be, well, rich. 3. An additional math renderer, part of our equation-specific editing widget, so that authors can also INPUT formulas in an appealing richtext flow.[1] See the great demos by for examples. You read that correctly - not one, not two, but THREE SEPARATE MATH RENDERERS ON THE SAME HTML PAGE, each of which different due to balancing on the trade-offs of performance, coverage and visualization. I hear you cry: – Well, this is clearly horrible design, simplify and streamline it! Indeed! My thoughts exactly. But the GREAT SOLUTION, the one that solves this problem not only for me, but for the ENTIRE MATH-ON-THE-WEB DEVELOPER ECOSYSTEM, is not for me or my team to implement. This renderer medley can be traced to a single root cause - the absence of ubiquitous support in modern browsers. If you are not familiar with MathML, it is a W3C and ISO standard and a core part of HTML5. MathML does a great job of providing a single language for representing mathematics in structured documents, especially web pages. But while we have that great language, we lack major browser implementations – in fact only Firefox has GREAT MathML support, and has long been the browser-lead in math support. A different perspective tells us that we are just two browsers short of having the tide turn overwhelmingly towards native rendering. I am referring specifically to and . Having native support would allow us – the mortal developers interested in providing exciting and powerful math-enabled web applications – to sleep calmly at night and work proudly at day. And hence my sincere plea to all major browser vendors: ------------------------------------------------------------------------ PLEASE, DO THE MATH. ------------------------------------------------------------------------ P.S. How is the native MathML solution better? - BEST. PERFORMANCE. POSSIBLE. Your browser will be capable to render MathML the moment it loads, just as it can CSS. No extra load times needed. - THE DOM WILL SET YOU FREE As math-on-the-web developers, we need to select into and manipulate mathematical objects, just as all web developers need to manipulate forms and input fields. I want my cool math interactivity widget to be an easy drop-in for any webpage, just the same way that a jQuery widget is. And we can’t have that without equations being a proper participant in the HTML DOM – CSS would have never taken off if say <div> and <span> elements only existed for sites that had first loaded a third-party css.js library. - OUT-OF-THE-BOX ACCESSIBILITY Exposing the MathML source of an equation directly in its web page[2] will be the default state of any HTML5 web page. Math-to-speech and Braille adaptors can then simply use the raw HTML as-is. P.P.S. If you are interested in showing your personal support for adding native MathML, add your vote and voice to the public issues: - Edge MathML support: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6508572-mathml - Chrome MathML support: https://code.google.com/p/chromium/issues/detail?id=152430 Personally, I have joined an effort to promote MathML publicly and to remind developers of its many strong suits and far-reaching benefits to the web develpment ecosystem. You can visit our MathML Association website, or follow us on Twitter at @mathml3. [1] We also have an upcoming equation button palette to put the WYSIWYG cherry on our cake. [2] which you can also do today if you manage to carefully jump through the right JavaScript hoops