Minutes: MathML Core Meeting of August 5, 2019

The meeting was recorded:
https://benetech.zoom.us/recording/share/3rVcAJ4kqCpDEVu1FQcOtIzApcNt8lPem_K92ulyGsGwIumekTziMw

Next meeting in three weeks due to people being away for vacations.

Attendees:

   -

   Neil Soiffer
   -

   Fred Wang
   -

   Sam Dooley
   -

   Rob Buis
   -

   Patrick Ion
   -

   Brian Kardell (late)
   -

   Bruce Miller



Thanks to Brian for taking notes until a lawn mower made that impossible :-)
Agenda:

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

Collection of MathML documents:

 https://lists.w3.org/Archives/Public/public-mathml4/2019Aug/0000.html



   -

   FW: My idea was if we had a lot of documents I could run them against
   our chromium build and see if we have crashes or something.  We have run
   against many, we found some fatal errors/crashes and we've worked on
   addressing those. We still have some issues, mostly related to the fact
   that tables use old layout code and not Google's new LayoutNG which is
   replacing it.
   -

   NS: What about the old test suite?
   -

   FW: Yes, we need an archive of documents.  Do you have a link?
   -

   NS: (searches)
   -

   FW: I see in MathML2 there is an archive with the test suite, but not
   for 3
   -

   NS: I know they are there - I will ask David C.  He will know better. I
   will take an action item on that.
   -

   ACTION: NS to contact David C about MathML 3 testsuite archive
   -

   BK: How does this work for wikipedia?
   -

   FW: The MathML is there, but hidden.
   -

   NS: It’s there for accessibility; the CSS mess is hidden to AT

DOM/IDL #83 <https://github.com/mathml-refresh/mathml/issues/83> (update
from Brian?)

   -

   BK: submitted ~280 WPT tests.
   -

   BK: sounds like Firefox is willing to match the interface we want,
   probably via a name change first
   https://bugzilla.mozilla.org/show_bug.cgi?id=1571487
   -

   FW: two things -- renamings and exposing them. Which are they doing?
   -

   BK: SVGForiegnElement is a fiction -- thought Firefox had but they
   don’t. So name doesn’t currently matter. Added comment that it should be
   HTMLOrForeignElement mixin.
   -

   FW: but the name should be testable, so it does need to be resolved.
   -

   BK: maybe they should be moved up to element. So it doesn’t matter where
   they are, they just need to be made available.  Also opened
   https://bugs.chromium.org/p/chromium/issues/detail?id=835571#c4available
   -

   FW: isn’t the name exposed to the web, so it is observable.
   -

   BK: Mixins aren't themselves user-observable AFAIK - I think the
   question they are asking has to do with more like: if we created a brand
   new element, how do we know it exposes the right things.  Depending on
   where we put things, what do they get vs which interfaces do you have to
   mixin?
   -

   FW: the name is in the MathML spec, so something needs to be decided.
   -

   NS: HTMLOrSVGElement name is in HTML spec.
   -

   BK: Literally just the name in HTML, just ~six characters need to change
   in the entire world (of specs).
   -

   FW: what needs to happen?
   -

   FW: uses Rob’s patch, then add it WebKit and then get it fixed in Gecko.
   -

   BK: I think we should change the mixin name to HTMLOrForeignElement in
   our patch (chromium link above) and submit that upstream - align with FF on
   that and then try to get webkit to follow suit.
   -


   https://searchfox.org/mozilla-central/source/dom/webidl/Element.webidl#165

CSS painting order #52 <https://github.com/mathml-refresh/mathml/issues/52>
(anything new?)

   -

   NS: FW changed the examples from using mtext to mn to avoid the
   mrow-spacelike issues. I updated my post to show what a bunch of tools
   produce.  They are, I guess, a little different with the negative CSS
   Margin. MathPlayer supports negative lspace/rspace that the others don't.
   Fred, I didn't look, but when you changed mtext to mn in your example - did
   that change the outcomes at all?
   -

   FW: Hm… I'm not sure.  I don't think it changes, but we have to check.
   -

   NS: I think negative spaces are generally a bad idea.  But there has to
   be some way to do tricky things we hope people don't do. Mpadded? Mspace?
   -

   FW: The plan for now is to not implement native spacing in MathML core.
   -

   NS: For all of them
   -

   FW: Yes.
   -

   NS: no action item for now then.  I hope it is very, very rarely used,
   but I will admit I have used it myself.
   -

   PI: It's clear that people want to do as you have suggested you've done
   from time to time.  These days I feel they would expect technology would
   provide that capability. I hear you saying you would not like to have that
   for now, is that right?
   -

   FW: Yes, I think we see that there are some things that are achievable
   with negative margins and it is not in the plan or clear yet. I filed an
   issue about it some time back: #40
   <https://github.com/mathml-refresh/mathml/issues/40>.
   -

   PI: OK, if that is what technology requires.
   -

   NS: Ok, so I think that there is an action item from last week to
   determine how hard it would be to change the chromium painting order to
   match others?  We definitely had some differences of opinion on what was
   'natural'.
   -

   FW: no progress yet on that.

Vertical writing mode #18
<https://github.com/mathml-refresh/mathml/issues/18> (new comments since
last meeting)

   -

   NS: Fred you got a comment with some samples who said, if I remember
   correctly, that you could kind of do whatever you want and nobody cares?
   -

   FW: What I originally got was from another colleague, but the comment is
   from someone on the Chromium team.  I think we were passing some and not
   others, and we were wondering after this comment whether this was worth
   fixing - it seems like it would be difficult and part of the problem is
   that it isn't clear what the 'right' way to do it is - Japanese vs
   Mongolian… The flow of the line is not the same.
   -

   NS: he had mentioned writing mode vs text-orientation - that raised some
   question about baseline to me.
   -

   FW: I guess it depends, if you use latin characters - you can see some
   samples in there.  I'm not sure actually. It's even more complicated when
   you have math. HTML Tables vs Fractions, they are different.  A matrix in
   mongolian math - do we just rotate it 90 deg?
   -

   NS: That's how it seemed to me.  I was looking back at the comments and
   what I was talking about was "I recommend not to support orienting parts
   differently from the root. It is possible to find such examples in real
   books, but the authoring cost is very high because, as you found, the best
   orientation varies by several factors, and that editors need to make a lot
   of decisions for every math expression. Often they don't look good no
   matter how it was typeset, editors need to make compromises. It was more
   common to typeset math in vertical flow 5 decades ago or more, but rarely
   seen these days, and I expect to see even less in future."
   -

   FW: We actually get some of this for free with LayoutNG, but I think the
   thing the person is commenting is do not rely on writing mode and then I
   think it is potentially a completely different layout.  If it is going to
   make things more complicated, let's not do it because it wasn't in our
   plan/roadmap - just 'experiment with it' and we have.
   -

   NS: The good thing is that issues were identified and raised
   -

   FW: Yes, we need as you said some experts.  I think there was something
   with a W3C Note, but we need someone who is an expert and what is/should be
   intentional even in what we see in examples.  Propose we forbid changing
   css writing mode in math for now, and we'll revisit later.
   -

   NS: Any objections?
   -

   PI: Very sensible.
   -

   FW: This is also how it is implemented in Firefox.
   -

   NS: What about webkit
   -

   FW: I don't know.
   -

   NS: I can't imagine they look at writing mode
   -

   RESOLVED: can’t change css writing mode and text orientation in <math>
   unless someone comes up with a compelling reason to change that (might
   include implementation issues)

Invalid markup #15 <https://github.com/mathml-refresh/mathml/issues/15> /
out-of-flow positioned elements #16
<https://github.com/mathml-refresh/mathml/issues/16>

   -

   NS: I'm not entirely sure how these wound up together like that
   -

   FW: I wrote it this way and added to the agenda because when you have
   out of flow, the html says they should not participate to the layout… If
   you have a fraction and…
   -

   NS: how does someone say out of flow?
   -

   FW: something like position:absolute
   -

   NS: Ok
   -

   FW: So basically, it is as if the element doesn't exist during the
   layout.  So, this is then 'invalid' and it comes back to previous problems
   of 'we don't have enough children'.  Similar with display: none for a
   numerator, for example - and the fraction looks as if it only has one child.
   -

   NS: Is there any HTML that requires a child?
   -

   BK: What does it even mean to require a child here?
   -

   FW: I think we would just generate some anon empty boxes, but I think
   rob had …?.  I need to check.
   -

   RB: we have a util method to layout children in a row
   -

   NS: So you don't change the DOM?
   -

   FW: No, this happens during layout.
   -

   NS: so if we flip to #16 and it's about display:none - they would work
   the same way as in your proposal here?
   -

   FW: If you have fewer children than expected, they are treated as
   'empty'.  I was suggesting that if they were absolute it was as if they
   didn't exist - basically, you can't.
   -

   NS: I think we have resolution on both of these items:
   -

   RESOLVED: For #15, if there are too few children, the missing elements
   are treated as empty mrows so that the parent element looks reasonable. If
   there are too many, the extra children are treated as being part of an mrow
   with the last element in layout. Neither the DOM nor the layout tree are
   changed.
   -

   RESOLVED: For #16, display:none and position:absolute (and maybe other
   values) will be treated as if the element wasn’t present, so the error
   repair for #15 of too few elements will kick in. If someone doesn’t want
   (say) a denominator being moved to a numerator, they can add an mrow around
   the thing they are positioning so that the element sticks around (just the
   child of the mrow is absent from layout).
   -

   [PI: There was discussion of missing children of definition lists some
   time ago

https://github.com/twbs/bootstrap/issues/4062.  But there doesn’t seem to
be agreement on how to deal with authored bad markup there either.   The
notion of just filling missing children in with empty boxes (in rendering)
seems fine, as does treating the last child required as including with it
any succeeding spurious children, all in a wrapping <mrow>.]



Next meeting is in three weeks 26 August.