- From: Frédéric Wang <fwang@igalia.com>
- Date: Fri, 22 Feb 2019 15:44:54 +0100
- To: www-math@w3.org
On 27/07/2016 11:31, Frédéric Wang wrote: > 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 > > > Moved to https://github.com/mathml-refresh/mathml/issues/37 https://github.com/mathml-refresh/mathml/issues/36 https://github.com/mathml-refresh/mathml/issues/35 https://github.com/mathml-refresh/mathml/issues/34 -- Frédéric Wang
Received on Friday, 22 February 2019 14:45:29 UTC