Re: MathML Core meeting minutes: 22/7/19

I don't see any resolution in the notes. Is this correct:
- for CSS width/height we ignore them for the specific layout defined in
MathML Core? (and defer to CSS for other layout)
- Same for margin-collapsing?
- css painting order: postpone until we do more testing.

(I thought one of my action item was to write resolutions on github and
update the core spec)

On 22/07/2019 22:06, Neil Soiffer wrote:
>
> 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.
>
>
>
>

-- 
Frédéric Wang