Minute: MathML core meeting of Feb 3, 2020

MathML Core Meeting of Feb 3, 2020



Attendees:

   -

   Fred Wang
   -

   Bruce Miller
   -

   Brian Kardell
   -

   David Carisle
   -

   Neil Soiffer
   -

   Murray Sargent
   -

   Rob Buis


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



The meeting was recorded:
https://benetech.zoom.us/rec/share/1Yt2dbHqyExOT7PfzBD-YacuP5rPeaa813VPrqJbyRvhDumNQxpkOeflEuf1Lh6b
Operator update?

No updates this week.
Explainer update

BK: a lot of people on the TAG had no clue about MathML or math. So some
updates to the explainer are needed. I’ve made some changes based on a lot
of conversations back and forth with Alice Boxhall.  I have sent a PR at
https://github.com/mathml-refresh/mathml-core/pull/20 - would like to get
the group’s ok to merge it..

NS: I didn’t see anything controversial

DC: Neither did I. Just merge it.
more on mrow-like: #183
<https://github.com/mathml-refresh/mathml/issues/183> #184
<https://github.com/mathml-refresh/mathml/issues/184>

NS: Part of our homework from last week was to try to review Fred's
proposal… I did a few days ago, but I can't recall a lot of my thoughts
beyond that I think it is important to handle the math element specially.
Did anyone else get a chance to read through the proposal and had
comments?  Fred can you recap..?

FW: The basic idea is to keep everything consistent - unknown elements
would be 'mrow-like'.  If we decide to not make them N we…

NS: That means something like mstack would be row-like

FW: Yes, as long as it is in the mathml namespace and unknown.  But also
what happens if you put something non-mathml (like svg) in a place where it
isn't valid.  We talked about maybe not creating boxes in the layout tree,
but it all depends on what we decide here and what is 'normal'...  But
that's separate, we are right now just talking about unknown mathml
elements… Can we treat them (for layout) as mrow.

DC: Seems ok, you can still style it kind of however you want if you
polyfill, what you are talking about here is what to default.

MS: What if you put an img in there, you'd want it to display

FW: We don't have interop on this one, I'm not sure which is logical
actually.  What is going to happen when an a math element occurs outside a
math root - like in a paragraph.

NS: I'm sure the parser says what will happen… I do think we need to
specify what will happen when JavaScript inserts the element into the DOM.
  Mglyph is an interesting case because it should only be inside leaf
content and mrows can’t go into leaf content.

FW: mglyph was removed from core last week

NS: That's why it is interesting - because it is inside an mi or something,
and then you would treat it as an mrow?

FW: It's the same as how do we layout an image inside an mtext -- it's not
really specified.

NS: So I guess this is a bigger issue… if someone put an mfrac inside an
mtext - do we specify what should happen here?

FW: It's the same case, basically… It's invalid in MathML and we don't say
how to lay it out…

NS: Brian, is this the sort of thing TAG will generally raise?  What
happens in HTML if I mix something up with SVG. Where is this specified?

BK: I think, like you said NS - if you put a circle element in the main
HTML document - we can make a test, but I am sure the parser doesn't know
that is SVG, so it will be exposed in JavaScript as an HTMLUnknownElement -
FW, you can correct me if I am wrong, but I _assume_ that this also maps to
the class it will use for layout - so, effectively, it will become a span
for layout purposes.

FW: That seems right basically, I expect that is what happens here.

NS:   so if someone throws mglyph inside mi…

FW: Does it create a layout node inside the layout tree? If so, it will be
used by mi…

https://mathml-refresh.github.io/mathml-core/#layout-of-mtext

NS: Let's reel it back in because we're wandering into all of these other
topics, but these aren't the actual issues we're supposed to be
discussing.  On this topic (183) I think your simplification is fine and I
support it.

DC: I also support this.

NS: RB, you are implementing - what do you think?

<lots of unminuted "what if" scenarios about prefix,postfix,infix
implications of being treated as an mrow>

Resolved: accept #183 with the change for math

Resolved: accept #184

#29 -- mfrac bevelled attr

NS: I am a little worried about this being able to be done with a polyfill

FW: MathJax supports it,right? So it is possible.

NS: They are measuring stuff to do that…

FW: Sure

NS: How do you measure stuff without measuring the children?

FW: The same for HTML Elements, you can do the layout with the web engine

NS: so - create the children, and then ask for the width…?

FW: Create a math element with 1 child, etc..  It's not really efficient,
but it can work

NS: This is intercepting a pretty major element, so I kind of worry about
that

FW: In theory the solution would be to rely on the CSS layout API, I'm not
sure how to paint the slash, that might require another thing even..
Mozilla decided to disable the beveled attribute, it was never implemented
in webkit, we don't plan to implement in chromium - I guess not many people
have complained

NS: But I don't know that this is a real useful data point because the
situation on the ground is that people have to use MathJax… MS, do you
support beveled fractions

MS: Yes, we do

DC: If we did put it in core, how much of a complication is that in the
implementation

FW: There is still this problem of intrinsic size, you cannot just stretch
vertically the slash - you have to make it thicker, which makes the width
depend on the height…

NS: Looking at MathPlayer it just draws a line.

FW: If it becomes tall..?

NS: Yeah it probably looks terrible.  Maybe this is something everyone can
think about this week. To me, I would not be thrilled with having to write
a polyfill for mfrac, because it means you're kind of intercepting half of
mathml --- I'd like to see a polyfill try to do this… Fred is this a thing
you feel like you could do

FW: No, I don't have the time/willingness to do this. I'm not sure why we
would put it in core if no browsers will implement it though right? That's
the point of core…

NS: There are indicators that indicate that it is useful

FW: I think David said…

NS: Do you have usage statistics David?

David:

FW: I dont recall seeing this in printed books

NS: I think it occurs more in elementary grades

NS: Bruce are you able to get statistics?

BM: the easiest way to get metrics for us is when they fail :)

DC: Even if it is used, I expect that fred is right - if you push it off
the browsers plate, it's not their problem it's ours.  I think there's a
point that it might be sort of useful, but if it invalidates everything
about CSS and browsers aren't going to do it… what can you do?

MS: I checked what office math can do - the largest slash it has is about 3
line heights and then it just doesn't get any bigger. I guess there's just
an assumption that that's bigger than you would ever need.

NS: I think that is what fred is saying thought

DC: But then you can't use it for the one case it is actually really used

NS: No, this is just used in min/max - it wouldn't literally be that

FW: I'm looking at stats from TeX, it's not really used

BM: Possibly because it wasn't supported on the MathML end… It always made
me sad because when they are appropriate, they look really good.

NS: Let's everyone try to think about this this week - comment on the issue
if you have thoughts, and we'll put this at the top of the agenda for next
week..


https://github.com/mathml-refresh/mathml/issues/55#issuecomment-475916070

https://github.com/mathml-refresh/mathml/issues/55#issuecomment-475887469

Next meeting next week