Agenda for MathML Core meeting 2019/03/18

Hello everyone,

I updated the agenda for the next meeting:

https://github.com/mathml-refresh/mathml/issues/8#issuecomment-472173526

During the last meeting I mentioned that Mozilla people didn't like the
complexity of the current scriptlevel stuff. They recently refactored
font stuff and the MathML implementation is causing issues again [1]. At
Igalia, we are also concerned about the complexity if we have to
implement this in WebKit/Chromium.

Emilio Cobos (Mozilla) joined our CG and will try to attend our next
meeting in order to discuss this in more details. Hence I would like to
put this as the first item. Please take some time to read the summary
below so that you can think about it before the meeting.

I don't know how much time we will be able to spend before and/or during
the meeting on the invalid markup & deprecation topics, but I guess
Emilio's feedback will be useful here too as this somewhat also affects
Firefox (which has more complex handling invalid markup implementation
and more complete MathML implementation than other browsers).

== SUMMARY ==

(1) scriptsizemultiplier and scriptminsize attributes: Is it really
useful for users to specify them or in practice or can default/font
values be used instead?
  See
https://mathml-refresh.github.io/mathml-css-proposals/math-script-level-and-math-style-comments.html#scriptsizemultiplier-and-scriptminsize-attributes
  PROBLEM: In the former case, that would mean implementing more CSS
properties.

(2) Is is really important to have a script min size in MathML?
Alternatively we could either (a) set a max value for script level
(decrease is exponential, so it should be small like in TeX or Microsoft
Word) or (b) continue to decrease font-size and rely on other mechanisms
to address the problem (UI config?, a11y?)
  See
https://mathml-refresh.github.io/mathml-css-proposals/math-script-level-and-math-style-comments.html#scriptsizemultiplier-and-scriptminsize-attributes
  PROBLEM: In addition to the actual font-size (constrained by script
min size), CSS code has to track the unconstrained one otherwise we
can't go back to the original size by increasing the script level.

(3) Define exactly how the font-size/scriptlevel interacts in term of
CSS inheritance. Paragraphs from [2] [3] indicates the font-size change
when font-size is not specified. When font-size is specified, MathML
full [3] seems to say we should apply script level before font-size
change. I personally think order is not so important: (a) Changing
font-size *inside* a math formula is probably not super useful in
practice (b) In any case, people can decide to wrap the font-size change
in an mrow-like element (e.g. non-browsers would do <mstyle
mathsize="...">) avoiding the interaction with scriptlevel.
  PROBLEM: The choice of interaction can make code complicated [1]. We
should probably choose the most simple option here.

(4) Script level increment in munder, mover, munderover scripts
  See
https://mathml-refresh.github.io/mathml-css-proposals/math-script-level-and-math-style-comments.html#script-level-increment-in-munder-mover-munderover-scripts
  PROBLEM: Scriptlevel change cannot be implemented with pure CSS, so
this is adding some hacks to Firefox, violating layout code invariants [4]

(5) Should we take OpenType MATH values into account?
  See
https://mathml-refresh.github.io/mathml-css-proposals/math-script-level-and-math-style-comments.html#opentype-math-values-scriptpercentscaledown-and-scriptscriptpercentscaledown
  PROBLEM: It is unknown whether the CSS code can read the font tables.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1534494
[2]
https://mathml-refresh.github.io/mathml-css-proposals/math-script-level-and-math-style-explainer.html#css-math-script-level-property
[3] https://mathml-refresh.github.io/mathml/chapter3.html#presm.scriptlevel
[4]
https://dxr.mozilla.org/mozilla-central/source/layout/mathml/mathml.css?q=mathml.css&redirect_type=direct#243
https://dxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLmunderoverFrame.h#57

-- 
Frédéric Wang

Received on Wednesday, 13 March 2019 19:17:57 UTC