Why is native support important?

MathML in Chromium



Why is native support important?

For years, authors of web pages have used several methods to write and display formulae (text for simple equations, ASCII art, PNG images…). Recently, other approaches have become popular e.g. using a Javascript layout engine to format equations. If you are not familiar with mathematical writing or web technologies, it may not be immediately obvious why native math support is needed. Mathematical formulae basically combine two key features: text and graphical rendering (use of mathematical glyphs, font properties, complex text layout, typographic rules, stretchy operators, fraction bars, root overline, table lines etc) and usual box layout (with special spacing, positioning, linebreaking, bidirectionality, hierarchical structure of information, etc). MathML provides these features in a web context. MathML provides the same sorts of properties that are so natural with other textual elements that one may not even realize them:

  • Layout is performed efficiently. Native text elements are laid out immediately without “flashing”, and you can put several hundreds of such in a page without waiting several seconds for rendering completes. It isn’t contingent upon first downloading scripts or bundles, and then parsing and executing them - the web engine runs binary code (optimized by the compiler) allowing fast execution.
  • Reflow is performed automatically. Many things may cause part of the web page to be reflowed. For example if you resize your browser window, if you zoom in, if you change your CSS or font preferences, if the page content is modified by some Javascript program… As a page author, you do not need to worry about that: Your browser engine will take care of reflowing efficiently.
  • It has good visual quality. Text is drawn using an outline font that scales well whatever the font-size or zoom level. Advanced techniques such as font hinting, antialiasing or subpixel rendering are also used for rendering the text. Web engines also have features for box layout e.g. internally handling coordinates and sizes as integers rather than floats to avoid rounding errors with fractional pixels.
  • Visual rendering is fully controlled by font and styling. As long as the specification is accurate enough then for a given configuration, the text should render the same in all web engines.
  • Content is compatible with the rest of HTML5 technologies in order to provide the best experience for Web users and developers. Authors can use CSS to specify the style of the text (including Web fonts), usual features automatically apply. It is exposed using the DOM API and can be modified dynamically via Javascript.
  • Content works well with your browser UI: You can zoom in to make it bigger, or zoom out out to make it smaller without loosing rendering quality. You can select and copy part of the text, you can use the “find” menu to search some text, you can change your font or CSS configuration and have it applied, you can use keyboard or caret navigation, handle hyperlinks with the usual UI, etc
  • The information is properly exposed to assistive technologies. Although the markup provides a visual rendering, web engines also expose an accessible tree with the essential information for assistive technologies.

Existing non-native alternatives for mathematical rendering only partially fullfill these expectations and provide some non-standard hacks to work around missing features. If, as we believe, mathematical rendering is important then it should be treated as any other human language and be rendered natively by web engines!