Re: Agenda for MathML Core meeting 2019/03/18

On 13/03/2019 20:52, Murray Sargent wrote:
> I agree that the script-level attributes aren't used much since script level choices are automatic in modern math display engines. So these attributes shouldn't be in MathML core. The only script-level related attribute that should be supported in core is display vs inline, which affects the script levels of fraction base-level text. People often want to have display formatting for equations that are inline for some reason or another. E.g., on a test sheet, some text is on the left and the equation follows on that line and the author wants the equation's base-level characters to be legibly big. 
>
> Also in displayed equations, people may want all base text to have base-level size regardless of the fraction nesting level. That choice is probably best made as a document property that's inherited by math zones inside the document.

Thanks Murray. Right, just to be sure everybody is on the same page,
MathML actually provides/generalizes these features using the related
scriptlevel and displaystyle features:

https://mathml-refresh.github.io/mathml/chapter3.html#presm.scriptlevel

That's why the CSS proposal defines both math-script-level and
math-style simultaneously:

https://github.com/mathml-refresh/mathml-css-proposals/blob/master/math-script-level-and-math-style-explainer.md

There are two levels of discussion:

(1) Which MathML attributes we want to provide in MathML Core for user
customization purpose (display, displaystyle, scriptlevel,
scriptminsize, scriptsizemultiplier)? It seems to me at least display,
displaystyle, scriptlevel are needed to emulate TeX's commands $...$,
$$...$$, \displaystyle, \textstyle, \scriptstyle, and
\scriptscriptstyle. I'm not sure how useful are the scriptminsize,
scriptsizemultiplier attributes.

(2) Since all of these are affecting font-size (displaystyle indirectly
because of the fraction case you mentioned) and follow some kind of
inheritance, the appropriate place to implement them in browsers is the
CSS module which is relatively independent from the rest of the code. We
should provide a clear and simple implementation that does not add extra
complexity and does not mess up with other modules (e.g. layout or DOM).
That's currently not the case in Gecko/Stylo and we only have very basic
implementation in WebKit/Chromium.

-- 
Frédéric Wang

Received on Wednesday, 13 March 2019 22:10:35 UTC