- From: Frédéric Wang <fwang@igalia.com>
- Date: Wed, 27 Jul 2016 11:31:38 +0200
- To: "www-math@w3.org" <www-math@w3.org>
Hi readers of the Math WG mailing list, In a previous message, Murray Sargent indicated that his two main complaints about Presentation MathML were "1) lack of an explicit n-ary element (for integrals, summations, products, etc.) and 2) lack of document level math properties, like default math font". However, MathML already has a mechanism to describe such n-ary constructions based on the mo/munderover/msubsup elements and the largeop property ; Gecko & WebKit rely on them to use the appropriate layout constants. The second point is more interesting (especially fonts) so let's open a discussion here. As you know, stylistic properties in web engines are described using CSS. All Web authors are familiar with this mechanism and it is a very important feature for them. Users of web browsers can also use custom user stylesheets to specify their preferred default style, possibly overriding the one of page authors. However, the MathML specification does not say much about CSS and so web engines developers have to do their own interpretation, leading to incompatibilities between implementations. Some parts of the discussion below may be out of the scope of the Math WG but I think some hints should be provided in the MathML specification anyway. First, CSS is much more powerful than the <mstyle> inheritance mechanism. That latter element should probably be made compatible with CSS or at least should reuse it as much as possible. This is discussed in the other thread: https://lists.w3.org/Archives/Public/www-math/2016Jul/0024.html The specification should probably also explain how many CSS properties (e.g. margin, padding, border etc) should be handled for MathML. At the moment, Gecko and WebKit essentially ignore these properties in most cases. Anyway, the MathML specification is too vague about the exact rendering of math elements to open this discussion so I'll postpone it for a later thread. The default visibility for the mphantom element should be "hidden". Although it can be hidden by other mechanisms, using CSS is the most natural way to do it and this also has implications in other parts outside the rendering module (e.g. the a11y module). Many properties should be reset on the <math> element to avoid unexpected things. Here is a non-exhaustive list extracted from bug reports: * Inheriting the following properties can cause excessive spacing of mathematical formulas: text-indent, line-height, word-spacing, letter-spacing. * In some countries and languages, text is written from right-to-left while mathematical formulas are written from left-to-write. Hence it is wrong to inherit the direction and we reset that property to left-to-write on the <math> tag. Per the MathML specification, authors should explicitly use the "dir" attribute on the <math> element if they want to force the overall direction of the mathematical formulas. Similarly, the writing-mode should probably be set to "horizontal-tb" by default. * Some properties give poor rendering in math formulas or are confusing with the mathvariant style. They should be reset too. This includes at least font-style or font-weight. Finally, one of the most important issue is the choice of the math font. Note that most stylistic math properties are actually included in the font itself so it's great that authors can just use the CSS font-family to select their preferred fonts (possibly provided as Web fonts), and make it consistent with the rest of the page. However, to determine the default math fonts, some mechanisms should probably be formalized and implemented in web engines: 1) Text fonts are not appropriate for math layout. Hence making the <math> element inherit the text font is a very bad idea. Ideally, web engines should have a mechanism to try and find math fonts in the specified CSS font-family lists and to fallback to known math fonts on the system. 2) One consequence is that we are likely to get different text and math fonts and so inconsistent font-size. Instead of making the <math> element inherit the font-size, Web engines should probably have a mechanism to automatically adjust the font-size. 3) Even with this adjustment, the style of the font faces of the text and math fonts may be inconsistent. Many text fonts have a math companion e.g. STIX / STIX Math, Latin Modern Roman / Latin Modern Math, DejaVu Serif / DejaVu Math TeX Gyre etc It would be good to have a mechanism to map a font to its math companion (probably this should be discussed on the Open Font Format mailing list). Then the font-family can be determined using this mapping and this solves all the issues of inconsistent style and font-size. So to summarize, the idea to determine the default font-family / font-size on the <math> element would be: a) find a math font that fits best (font-size and fontface style) with the inherited font-family and b) adjust the font-size if necessary to match the parent font-size. Finally, for the record the user agent stylesheets of WebKit and Gecko are available here: https://trac.webkit.org/browser/trunk/Source/WebCore/css/mathml.css https://dxr.mozilla.org/mozilla-central/source/layout/mathml/mathml.css Frédéric
Received on Wednesday, 27 July 2016 09:32:31 UTC