Re: Minutes: MathML core meeting 13 Jan, 2020

Hi,

Regarding my action point, I downloaded Google Chrome Canary for OS X, 
version 81.0.4027.0. Using chrome://flags you can can see the 
experimental flags and MathML is not listed there. I think this is best 
for now as the implementation has just started, but once the 
implementation is reasonable we will probably want to offer Canary 
versions, so at some point we should ask Google how/when MathML would 
get enabled in Canary builds.

Regards,

Rob.

On 1/14/20 12:02 AM, Neil Soiffer wrote:
>
> MathML Core Meeting of Jan 13, 2020
>
> Thanks to Brian for taking most of the notes.
>
> Attendees:
>
>  *
>
>     Fred Wang
>
>  *
>
>     Bruce Miller
>
>  *
>
>     David Carisle
>
>  *
>
>     Brian Kardell
>
>  *
>
>     Neil Soiffer
>
>  *
>
>     Rob Buis
>
>  *
>
>     Patrick Ion
>
>
>
>
> Regrets
>
>  *
>
>     Murray Sargent
>
>
> Agenda: 
> https://github.com/mathml-refresh/mathml/issues/8#issuecomment-573384227
>
> The meeting was recorded: 
> https://benetech.zoom.us/rec/play/7JV8d-mvqmo3EoKQ5QSDCqMtW47vfKis0CIW_6YEyBnkUXgKNwKvY-cUZOIMMsM0IDlQmLLvQ-cOd3DX?continueMode=true
>
>
>     Implementation
>
>
>      Upstreaming Status update
>
>  *
>
>     Rbuis: A lot of time off for holidays.. container patch for
>     math/mrow (the obvious children having things) was upstreamed…
>     That took a really lot of reviews and things, stuff we thought we
>     could do later that we had to do now… Google's fuzzing turned out
>     a bunch of things that we hadn't realized we'd need to handle
>     right away.  The lucky thing was we were able to turn things
>     around very quickly and get reviews and comments. We also landed
>     mspace which is needed for the tests and in doing both of these we
>     got a much better foundation with more answers.
>
>  *
>
>     NS: Does this mean that the real version of Chrome has this code
>     in it??
>
>  *
>
>     RB: Do you mean can users test this in an official release?
>
>  *
>
>     BK: Do we have a flag for MathML?
>
>  *
>
>     RB: Yes, it's MathMLCore
>
>  *
>
>     BK: Then I assume it would be in canary at least and afaik it will
>     go into releases more or less like normal, yes - and if you enable
>     it it should.  It won't be very useful - it will only render
>     things composed of only math/mrow/mspace, more or less.
>
>  *
>
>     NS: Sounds like a good productive holiday for you rob..
>
>  *
>
>     RB: Yeah, I will look into whether we can show it is in canary and
>     everything
>
>
>     TAG Review:
>
> BK: when we had our f2f, the two reviewers weren’t that familiar with 
> MathML and wanted to talk to others. They weren’t that familiar with 
> MathML. Wanted more info in “explainer”.  How MathML core works in a 
> very basic manner -- what is MathML at the very base level.
>
> BK: over the holidays I went back and forth with Alice Boxhalll 
> (https://twitter.com/sundress) and she made some comments on that so I 
> will do some more work on the explainer and maybe another document 
> (what is MathML -- elevator pitch?)
>
> RB: Who is the other reviewer.
>
> BK: Other reviewer is Hadley Beeman (https://twitter.com/hadleybeeman).
>
> NS: You might want to look at the intro material in MathML.
>
>
>     Elementary Math
>
> NS: I added elementary math support, but couldn’t make use of shadow 
> DOM without modify the DOM because can’t shadow MathML elements.
>
> BK: This should be a whole topic on it’s own.
>
> BK: Houdini custom layout might be a better solution
>
> BK: Rob/Fred -- if you had to implement the elementary math, how would 
> you do that? Would you create a shadow DOM? Would you just change the 
> layout without a Shadow DOM
>
> RB: I’m not sure
>
> BK: It doesn’t seem naturally to break the numbers apart and create a 
> new structure.
>
> BK: Shadow DOM is meant to for taking the light DOM and projecting it 
> into the shadow dom via slots. The elementary math is different in 
> that it is splitting up the contents and creating a new structure.
>
> NS: Here’s is Brian take with a new element so it’s not quite MathML: 
> https://mathml-examples.glitch.me/elementary.html
>
> [note: github version that doesn’t have as many bugs is at 
> https://mathml-refresh.github.io/mathml-polyfills/elem-math/]
>
> BK: This would be a good topic all on its own another day probably… 
> This is really just a mechanism for discussion - it is a fork of 
> neil's work that was just illustrating something.
>
> FW: Doesn’t this just involve numbers?
>
> NS: There are some natural extensions. See 
> https://github.com/mathml-refresh/mathml/issues/181
>
> NS: These include polynomial division, synthetic division, and systems 
> of equations. Maybe a way of dealing with some alignment issues. But 
> this is drifting off topic. Probably something for the general meeting.
>
> BK: If we were proposing elementary math today, I’m not sure that we 
> would propose that’s the way we would do elementary math today. I 
> think a custom layout is probably better than using a custom element 
> as in the example.
>
> NS: I did this over the holidays so we could have some concrete 
> examples on which to base a discussion.
>
> NS: I would like to have use mtable so MathML can be in the table.
>
> BK: See if I can summarize. The current state of things is that once 
> our implementation is done. We can’t do anything greater than what you 
> can do today other than lots of things can render. But if you want to 
> polyfill (really just transform), you can do that. The next step is to 
> have the ability to use the Shadow DOM on the MathML elements. That 
> would make mfenced work well. It will keep everything independent; you 
> can reason about the light DOM tree. For that, there’s a different 
> standard that is working its way through. It’s not ready to use, but 
> something to think about and maybe experiment with.
>
> BK: in the example, the tree remains the same. Not sure it is that 
> useful since this really doesn’t fit with what Shadow DOM is what to do.
>
> FW: maybe use mrow with a table layout on that.
>
> BK: that would be cool
>
> FW: not sure when that would be ready, but you could then just use CSS.
>
> NS: when you say use mrow, you are still talking about breaking the 
> numbers/polynomials into chunks.
>
> FW: yes
>
> FW: it would be interesting to see support for polynomials and see 
> what turns up with them.
>
>
>
>     Operator Dictionary (David)
>
>  *
>
>
>         any updates on fixing up entries
>
>  *
>
>
>         Make things more consistent and general review & fixup #87
>         <https://github.com/mathml-refresh/mathml/issues/87>#6
>         <https://github.com/mathml-refresh/mathml/issues/6>#151
>         <https://github.com/mathml-refresh/mathml/issues/151>
>
>  *
>
>     NS: we have a general rule in the operator dictionary that
>     horizontal arrows have the accent property. But there are arrows
>     that are sort of horizontal but have curves that point up/down,
>     and diagonals ones. Does it make sense to change all the arrows to
>     have accent=”true”. Any feedback?
>
>  *
>
>     FW: I want to make the operator more compact. I don’t know if this
>     helps.
>
>  *
>
>     NS: It simplifies the decision making property, probably doesn’t
>     change how compact the table. Not really sure.
>
>  *
>
>     FW: We could also say none of the arrows are accents.
>
>  *
>
>     NS: Definitely used for vectors, etc.
>
>  *
>
>     PI: Yes, arrows and harpoons are used. Northwest arrow isn’t out
>     of the question.
>
>  *
>
>     FW: Why not make all operators accent by default?
>
>  *
>
>     NS: Good question. I can’t think of a reason off the top of my head.
>
>  *
>
>     DC: If we drop accent, how bad would that be.
>
>  *
>
>     NS: I can’t think of a reason off the top of my head. Scanning
>     through the dictionary, I’m not seeing any problems.
>
>  *
>
>     DC:  I probably see more MathML than anyone, I don’t think anyone
>     uses that property.
>
>  *
>
>     NS: I’ve seen screwed up MathML accents.
>
>  *
>
>     DC: If we get the default rule right > 50%, that’s good.
>
>  *
>
>     NS: Proposal: think about it and discuss next week and hopefully
>     resolve next week.
>
>  *
>
>     FW: I have issue #176 about shrinking the table. I think it might
>     help.
>
>  *
>
>     NS: if you look at issue #87, at the top of the list is fraction
>     slash which I think is wrong.  I have this longer list of things -
>     inconsistencies I've found about priorities and so on that I
>     haven't submitted yet… I'm unsure how to resolve them and I'd hate
>     to edit the table and have it based on just my own impressions
>
>  *
>
>     DC: We have git and I think you should just do it in a branch and
>     we can do a diff
>
>  *
>
>     FW: This is only priority?
>
>  *
>
>     NS: this is priority and spacing, they tend to want to go
>     together.. .It does affect what Core cares about I think.
>
>  *
>
>     DC: I also found some surprising things, I think if we can sort of
>     do staged checkins …
>
>  *
>
>     NS: Yeah, I think we can try that - I can break them up into
>     different groups in a branch.  There are things where there are
>     like circled versions of a plus, and squared versions, maybe with
>     an equals sign beneath them… I'm not sure - sometimes there are
>     differences, like a cross product, that might make sense to have
>     different spacing and priorities - but… Are others?
>
>  *
>
>     PI: Vector spaces for multiplication, for example
>
>  *
>
>     DC: There are 3 classifications of spaces in …?....
>
>  *
>
>     NS: Yeah we have 5 classes instead of 3, slightly more nuanced I
>     guess, but it's not like we have a huge number
>
>  *
>
>     PI: People will sometimes add spacing around some feature that
>     they wish to call out.. But some of them are really absurd, you
>     don't really need a special spacing classification for them.
>
>  *
>
>     PI: You may sometimes want to distinguish…
>
>  *
>
>     NS: less than or equal to sit at a different priority, but have a
>     different spacing
>
>  *
>
>     B: It would seem a good rule of thumb would be a unicode glyph
>     could be thought of as an embellished operator
>
>  *
>
>     NS: I thought that, but it's not _quite_ true.  But, I'll check
>     stuff in and then I guess we can argue about it off the call.
>
>  *
>
>     B: It at least has the advantage of being somewhat predictable
>
>  *
>
>     DC: When we were doing this initially, we didn't even have the fonts.
>
>  *
>
>     NS: An empty set is a …? Not an operator - so we can pull that,
>     right?
>
>  *
>
>     DC: That is probably true
>
>  *
>
>     NS: I think there are things we could pull
>
>  *
>
>     PI: I wouldn't bother, in some sense. There are things that are
>     accented stretchy, and so on.
>
>  *
>
>     <discussion about what is stretchable>
>
>  *
>
>     FW: My proposal was to remove the accent property in the
>     dictionary, can we remove more? Some are duplicative, we have had
>     some discussions before.
>
>  *
>
>     FW: Could we remove the accent property from mo all together and
>     just use munder, etc, accentunder, etc?
>
>  *
>
>     [PI: You could even drop stretchy as something to specify; as
>     David points out in practice it comes down to a question for the
>     font.]
>
>  *
>
>     NS: Did we ever gather any usage stats on whether people were
>     setting accents true/false?
>
>  *
>
>     FW: It don't have concrete data that is recent, but I think people
>     are using it, I seem to remember …? Was using it
>
>  *
>
>     NS: could we use a polyfill, but that would be moving attrs around
>     in the real DOM.
>
>  *
>
>     FW: probably too big a change
>
>  *
>
>     NS: I agree.
>
>
>
> Meeting next week.
>