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

Sorry for leaving the resolutions out -- it is hard to minute and also lead
the discussions at the same time.

We did agree to ignore CSS width/height on all elements except math and
mtable as that simplifies implementations.

For implementation simplification, we agreed to do the same about
margin-collapsing (I think that is true for *all* elements).

CSS painting order was indeed postponed pending feedback about other
implementations (which is almost complete).

Indeed, you are right also about being tasked to update the appropriate
issues and spec accordingly.

    Neil


On Tue, Jul 23, 2019 at 8:07 AM Frédéric Wang <fwang@igalia.com> wrote:

> 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
>
>