FAQ

MathML in Chromium

Why is native support important?

Header 1

Header 2

Header 3

1

2

3

4

5

6

Simple HTML table

For years, authors of web pages have used several methods to write formulae (text for simple equations, ASCII art, PNG images…). Recently, other approaches have been 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. Let’s imagine a basic HTML table to illustrate some properties that are so natural that one may not realize them:

Layout is performed efficiently. One of the reason is that the web engine runs binary code (optimized by the compiler) allowing fast execution. Not only the table is laid out immediately without “flashing” but also you can put several hundreds of such tables in your page without seeing tables pending to be displayed or without having to wait several seconds before the rendering completes. Any change that requires a reflow will be similarly quick! Additionally, optimization is important for some devices with battery usage or low computing resource.

Reflow is performed automatically. Many things may cause part of the web page to be reflowed, including the table content. 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 the table and its surrounding content, minimizing the number of reflow needed.

It has good visual quality. The text in the table 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.

No external resources are required except for purely stylistic information. The text of the table may just be rendered with your system fonts and the whole layout is performed by your browser web engine. You do not need to rely on a third-party program or web service which are likely to cause many problems. For example: Are the terms of use of the program/service acceptable? Is it robust enough to be fast everywhere, not go down or crash? Will it be blocked by some proxy? Will it work if Javascript or CSS is disabled by the user? What about privacy and security of the service? How to work offline (e.g. ebook or web app) without embedding a copy of that third-party tool? Are there potential licensing, permission or disk space restrictions preventing such embedding? How are bug fixes and upgrades handled? Will layout be correctly performed if the page containing that table is mirrored in another place (e.g. web feed)? Or if the content is downloaded or copied & pasted? etc

Visual rendering is fully controlled by font and styling. The HTML table contains some text rendered with its own typeface features (typographic properties, design of glyphs…). More generally, the table content is rendered with some special style such as font family for the text, boldface for headers or alignment & spacing for rows and columns. All of these are well-defined by font data and style properties: As long as the specification is accurate enough then for a given configuration, the table 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 table (including Web fonts), usual layout features automatically apply to the table (line breaking, right-to-left rendering, vertical writing mode…), the table is exposed using the DOM API and can be modified dynamically via Javascript, the table can contain any HTML5 content or be embedded in an SVG schema using the foreignObject tag etc

Content works well with your browser UI: You can zoom in to draw the table bigger without loosing rendering quality, you can select and copy part of the table, you can use the “find” menu to search some text and get matches in the table, you can change your font or CSS configuration and have it applied to the table, you can use keyboard or caret navigation inside the table, handle hyperlinks in the table with the usual UI, etc

The information is properly exposed to assistive technologies. Although the HTML table markup provides a visual rendering, web engines also expose an accessible tree with the essential information for assistive technologies: headers, number of rows/columns, cell content etc For example, this allows visually-impaired users to easily browse the table and read its content. Note that the exposure is performed using standard accessibility APIs so that any applications can expose such a table and any assistive technology can get access to the table content.

Note that the above points make sense for any other HTML5 content, not only tables. In particular they would also apply to MathML when it is implemented natively in web engines. 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!

How does this fundraising work? How will the money be used?

Monetary contributions are raised from several organizations, companies or individuals willing to help. The funds will be used to support Igalia engineers for implementing MathML in Chromium. Please refer to the sponsors page for further details.

WebKit has MathML support... Isn't it straightforward to enable or port it to Chromium?

Google forked WebKit some years ago to manage their own web engine for Chromium and hence the MathML support in WebKit is not available in Chromium’s web engine. Moreover, the two code bases have diverged and porting code between them requires some work… In 2016, Igalia made some experiments to port WebKit’s MathML support to Chromium and demonstrated its feasibility. However, because Google developers are performing a complete refactoring of their layout engine, the most appropriate approach is to rewrite a MathML implement from scratch by relying on the new layout model.

Will Google accept adding MathML support in Chromium?

Chromium is open source and Google developers review and accept third party contributions. Igalia has made several contributions to Chromium in the past including the implementation of CSS Grid Layout in Chromium’s web engine. Regarding MathML, Igalia has been discussing technical points with Google and there is an agreement on the way to proceed. If you are curious, you can read the technical details.

But I heard Google did not want MathML / removed MathML in the past / thought MathML was insecure / did not trust third-party contributors / etc ?

Indeed, the story of MathML in Chromium is complicated and a lot of confusion was added by people who are not Chromium developers. This fundraising project is launched after technical discussions between Igalia and Google, leading to an agreement on the proper way to implement MathML in Chromium. The past history can thus be ignored, Google will accept Igalia’s contributions as long as they align on the goals of the Chromium project. Again, if you are interested in technical details, see this page.

Does that mean MathML will be supported in Google Chrome? What about other browsers?

This project applies to any browser relying on Chromium, including Google Chrome, Opera, Vivaldi, Brave, etc. Other browsers already have some MathML support or rely on a proprietary web engine so they are excluded from that project.

What about support in assistive technologies?

Accessibility is also very important for mathematics and assistive technologies already have some support via MathML. However, the present project focuses on the rendering engine of Chromium.