MathML Core meeting minutes: 22/7/19

The meeting was recorded:
https://benetech.zoom.us/recording/share/Cpi-78Mg2aCDmCwfo1gZ5y0GeYTGwy4aoDkX_dEaCZiwIumekTziMw


MathML Core Meeting of July 22, 2019

Attendees:

   -

   Brian Kardell
   -

   Neil Soiffer
   -

   Fred Wang
   -

   Sam Dooley



Agenda:

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

Brian update on DOM/IDL/Shadow dom? #83
<https://github.com/mathml-refresh/mathml/issues/83> #118
<https://github.com/mathml-refresh/mathml/issues/118>

BK: WhatWG suggested we create some WPTs. Just submitted tests that cover
~260 things (global event handlers, …). Tests for all the mixed in
interfaces.

BK: Avoids depending on how element actually is part of the tree. Not clear
why some are/are not mixins.
BK: Tests still need review.
New CSS Candidate Recs: Syntax
<https://www.w3.org/TR/2019/CR-css-syntax-3-20190716/>and Display
<https://www.w3.org/TR/2019/CR-css-display-3-20190711/#propdef-display> --
any impact on MathML?

BK: Shouldn’t be any impact on MathML of syntax spec.

NS: Display adds (I think) some new values. Any affect?

FW: Still working on details of how display works.  Currently we just do
the work. There is potentially desire to define new math display types, but
we don't know yet/aren't there yet. [ed: see more discussion below]
width/height #45 <https://github.com/mathml-refresh/mathml/issues/45> #50
<https://github.com/mathml-refresh/mathml/issues/50> #51
<https://github.com/mathml-refresh/mathml/issues/51>

FW: Not an issue except for <math> and <mtable>. Let’s just ignore w/h for
now on the other elements to simplify implementation.

FW: Ask publishers for feedback as to whether they want to add w/h on other
elements.

NS: Couldn’t do this before

BK: Publishers could have used polyfills, would have styled against the
different/generated tree

NS: I’m fine with keeping things simple because I don’t see a specific use
case.

BK: Doesn’t this depend on the display property

FW: I don’t think it matters except for math with uses display/block.

BK: width is ignored for inline

FW: we should ignore (so act like inline). mtable uses display-table.

BK: what happens in a token element where you make something
inline-block/block and set the width to 500px? Does our math layout get
messed up?

FW: In CSS, you layout the children and use that to get the size of the
element. So w/h of children will be taken into account.

BK: But on the <mi> or token elements, if you set them to display: block or
something, you _can't_?

FW: That is the question, the current proposal is that we ignore it.

FW: We define a new display value for most MathMLelements

BK: But a new display style for token elements seems good.

FW: Let’s postpone this for now. We need to talk with CSS folks about new
display styles for MathML. See
https://github.com/mathml-refresh/mathml/issues/56

FW: In Chromium, we read each tag and each tag has its own rendering and
have one display property with separate properties describing layout.

BK: Not sure this is better from a CSS point of view

FW: Agree it is a bit cheating, but we need CSS group feedback. Let’s start
with discussing this with Google and get a clean proposal.

BK: There are other people who can also be consulted prior to just putting
a proposal out to the whole world… It seems good imo to build some smaller
consensus and feedback before that…

Action Item: BK and FW talk with appropriate display.

margin-collapsing? #42 <https://github.com/mathml-refresh/mathml/issues/42>

FW: again, this depends upon display

FW: we agreed that we were going to support margin, question is collapsing?

FW: person from Google said skip it because it complicates things.

NS: proposal is to ignore for now or specifically ignore them in the spec?

FW: put in the spec that margins never collapse because it makes
implementation easier

FW: not clear if we have a use case.

NS: I don’t know of a good use cases, so I’m in favor of whatever is
easiest to implement.

SD: Agree.

BK: No opinion. Answer depends on what display model is.

css painting order #52 <https://github.com/mathml-refresh/mathml/issues/52>

NS: interesting screenshots, but unclear why on engine does one thing and
another does something different.

FW: Firefox always inline atomic painting order, others follow paint by
phase.

FW: Need to define how it should work. Text should overlap, so background
shouldn’t paint over text.

NS: Haven’t thought about this much, but at first blush, it seems like
background shouldn’t obscure the text. I think the MathML spec says
something about how to paint background.

SD: interaction with negative mpadded widths?

FW: maybe we should postpone to next call

NS: Let me look at the spec

BK: In issue, Blink example is the current Igalia implementation.

Action Item: NS to check spec and MathPlayer and MathJax implementations.

Brief discussion spacelike - #121
<https://github.com/mathml-refresh/mathml/issues/121>

Action Item: FW to add to core spec and NS to add to full spec <semantics>
should be part of space-like algorithm.

Update on implementation

BK:I tweeted a screenshot of some math rendering last week from our latest
build if anyone is curious in seeing
https://twitter.com/briankardell/status/1151527962510069760

FW: Large operators were recently implemented, but no vertical stretchy
chars yet.