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

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

-----Original Message-----
From: Frédéric Wang <fwang@igalia.com> 
Sent: Wednesday, March 13, 2019 12:17 PM
To: public-mathml4@w3.org
Subject: Agenda for MathML Core meeting 2019/03/18

Hello everyone,

I updated the agenda for the next meeting:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F8%23issuecomment-472173526&amp;data=02%7C01%7Cmurrays%40exchange.microsoft.com%7C45465ce7a6a349932bd708d6a7e89e52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636881014882707073&amp;sdata=gRJJK2m9WhpMPuta6%2Bwdr0Z%2BQ8GThYTijkfLdbzh0Ic%3D&amp;reserved=0


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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmathml-refresh.github.io%2Fmathml-css-proposals%2Fmath-script-level-and-math-style-comments.html%23scriptsizemultiplier-and-scriptminsize-attributes&amp;data=02%7C01%7Cmurrays%40exchange.microsoft.com%7C45465ce7a6a349932bd708d6a7e89e52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636881014882707073&amp;sdata=7PGl%2Bf4TP3bU0SduUh6Y36fcPfS0uCYOaIZJHuugVJs%3D&amp;reserved=0

  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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmathml-refresh.github.io%2Fmathml-css-proposals%2Fmath-script-level-and-math-style-comments.html%23scriptsizemultiplier-and-scriptminsize-attributes&amp;data=02%7C01%7Cmurrays%40exchange.microsoft.com%7C45465ce7a6a349932bd708d6a7e89e52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636881014882707073&amp;sdata=7PGl%2Bf4TP3bU0SduUh6Y36fcPfS0uCYOaIZJHuugVJs%3D&amp;reserved=0

  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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmathml-refresh.github.io%2Fmathml-css-proposals%2Fmath-script-level-and-math-style-comments.html%23script-level-increment-in-munder-mover-munderover-scripts&amp;data=02%7C01%7Cmurrays%40exchange.microsoft.com%7C45465ce7a6a349932bd708d6a7e89e52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636881014882707073&amp;sdata=ad5xtJ9auDlM54JLTUszaCkLO%2Fz1N%2FpUt2VjARYTaHI%3D&amp;reserved=0

  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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmathml-refresh.github.io%2Fmathml-css-proposals%2Fmath-script-level-and-math-style-comments.html%23opentype-math-values-scriptpercentscaledown-and-scriptscriptpercentscaledown&amp;data=02%7C01%7Cmurrays%40exchange.microsoft.com%7C45465ce7a6a349932bd708d6a7e89e52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636881014882707073&amp;sdata=5mnzctLNMZV0mCm8NqjVlgll7%2FNr02Et45UiLrL8IKo%3D&amp;reserved=0

  PROBLEM: It is unknown whether the CSS code can read the font tables.

[1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1534494&amp;data=02%7C01%7Cmurrays%40exchange.microsoft.com%7C45465ce7a6a349932bd708d6a7e89e52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636881014882717065&amp;sdata=XBtitW69gb9KQ%2Bsz29OuqTQMXvbm27ROVWO57BQOS8A%3D&amp;reserved=0

[2]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmathml-refresh.github.io%2Fmathml-css-proposals%2Fmath-script-level-and-math-style-explainer.html%23css-math-script-level-property&amp;data=02%7C01%7Cmurrays%40exchange.microsoft.com%7C45465ce7a6a349932bd708d6a7e89e52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636881014882717065&amp;sdata=rRFtajt1rDSvY0U7KhiRUFgl6roBlFO50rv1EZBJQ68%3D&amp;reserved=0

[3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmathml-refresh.github.io%2Fmathml%2Fchapter3.html%23presm.scriptlevel&amp;data=02%7C01%7Cmurrays%40exchange.microsoft.com%7C45465ce7a6a349932bd708d6a7e89e52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636881014882717065&amp;sdata=C0FH2GMfINLGrEp%2B8MgenzAE18g7E7a%2FNy8Zbe3kMPI%3D&amp;reserved=0

[4]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdxr.mozilla.org%2Fmozilla-central%2Fsource%2Flayout%2Fmathml%2Fmathml.css%3Fq%3Dmathml.css%26redirect_type%3Ddirect%23243&amp;data=02%7C01%7Cmurrays%40exchange.microsoft.com%7C45465ce7a6a349932bd708d6a7e89e52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636881014882717065&amp;sdata=n4%2FwVLttBdDJwgex4UU5tevSL%2BrpgEr4x2ZDeyBh2WQ%3D&amp;reserved=0

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdxr.mozilla.org%2Fmozilla-central%2Fsource%2Flayout%2Fmathml%2FnsMathMLmunderoverFrame.h%2357&amp;data=02%7C01%7Cmurrays%40exchange.microsoft.com%7C45465ce7a6a349932bd708d6a7e89e52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636881014882717065&amp;sdata=qfTzDZi%2BZgiuYl6FQw4OTxZJps7TZdLVUgqMeFNyj2o%3D&amp;reserved=0


--
Frédéric Wang

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