Minutes: MathML Core meeting, 18 May

MathML Core Meeting of May 18, 2020

Attendees:

   -

   David Carisle
   -

   Neil Soiffer
   -

   Brian Kardell
   -

   Murray Sargent
   -

   Rob Buis
   -

   Bruce Miller


Regrets: Frédéric Wang, Patrick Ion

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

The meeting was recorded:
https://benetech.zoom.us/rec/play/6ZwlI-7-qDI3H9LBsASDBf99W9Tpfa-sgSAYrPsMyUnnWnFVMwX3YOBBZLfPru5TFmCYyrknai_vopka?continueMode=true&_x_zm_rtaid=NsUsUT2FQcyJIBoqs9tqTw.1589839319611.b9d4ee6bd9bcde9de18ba74f30d76fe5&_x_zm_rhtaid=118

Need resolution for implementation

   -

   From Rob: The issue is about mroot. The spec says that base and index
   can only be one child. However last year we experimented with the index
   consisting of more than one child, and this is the current situation in the
   internal branch.

RB: We tried an experiment with mfrac and mroot. This is the state in the
internal branch and is at the experiment the spec has not changed.

BK: This is issue #15.

DC: What happens now if the expected number of children is wrong?

RB: it becomes an mrow

BK: can you be more specific. What are children here? Box children? Do text
node children count? Only element children? For example:  What about if an
element child is display:none?

RB: we don’t count out of flow children

BK: so box children, not elements.

RB: Yes. We probably need some more tests.

MS: I tried it in MS Word. It works by boxing up the extras into the last
child

NS: What happens with too few children

MS: You get an “empty” box.

NS: Is this a implementation problem to make it work with all elements with
fixed number of children?

RB: No, it is easy.

NS: Do you create an merror or write a console message.

RB: A console warning seems good.

DC: Does this change things in the DOM?

RB: No, this is only affecting rendering

DC: With my XML hat geek on I want to say it should crash and burn, but I
am actually kind of ok with this because they shouldn't make mistakes.  The
one interesting thing here is that it does something else, more forgiving -
which is maybe the more modern way, but it might actually do something
'useful' and people will then write invalid markup on purpose in order to
achieve the useful result.

NS: I understand what you mean, and I have not dissimilar feelings.  On the
other hand if we are trying to fit this into the HTML world, that seems to
be the way.  If people do want to follow suit in the XML world, it
shouldn't be too hard.  So… is there a resolution here? What is the status
to #15? It's open, it has a lot of labels.  It sounds like we did have a
resolution, it looks like Rob did some experiment and it was successful --
I think we decided that if that experiment was successful then that is what
we should do.  David seemed to express some reluctance

DC: No, I think the HTML way is to be kind to people and this seems quite
natural. I don't think there are compatibility issues - this is fine.

NS: OK, objections? …. No?  Ok, let's call that consensus.  Rob, you have
already done some upstreaming, will you have to change this?

RB: Yes, I think the thing to do is to explain to google this is the
approach we'd like to take and why and see how that goes.

DC:  A little off topic. When you upstream…. What's the current situation
with what we can look at with the implementation. Last time I looked, I
think only mspace and mrow were there so not very interesting.

RB: it should be in the build (you need to enable
chrome://flags/#enable-experimental-web-platform-features)

DC: From the public canary build on windows:



<math><mfrac><mi>a</mi><mi>b</mi></mfrac><mo>+</mo><msup><mi>x</mi><mn>2</mn></mo></msup></math>

RB: Also look at BK’s twitter:
https://twitter.com/briankardell/status/1253675060520419330 or igalia’s
twitter:
https://mathml.igalia.com/news/2020/04/23/forty-two-mathml-patches-upstreamed/#new
PolyfillsShort term strategy (what we can/should do now):

   -

   work onload/manually callable? MutationObserver?
   -

   use ShadowDom?
   -

   a good method for someone to choose the ones they want -- just script
   elements that load each individual polyfill or something simpler?

BK: We have a couple of challenges. If you are writing a polyfill today,
what are you using to make sure it does the right thing. The igalia build
is probably the best bet.

NS: Does the build work on windows?

BK: No.

BK: next one is how to do the polyfill. Some should use shadowdom and some
should be in the lightdom. We should have some framework for thinking about
that.

BK: I’d like someone to work with me and come up with an idea of how we
would do this and come up with advice on how to do it. Then

NS: there are three polyfills there now. Fred wrote one for mfenced. It
changes the DOM to the mrow equivalent. I just added one for ms that adds
the quotes and backslashes/escapes and changes the content of the ms
because core doesn’t handle the attributes or escapes. The other one is a
big elementary math polyfill. It changes the DOM and replaces it with an
HTML table that represents the elementary. I experimented with wrapping a
div around the MathML and putting the table in the shadowdom, but I don’t
think that is the version that is up there. There are real issues doing
this with shadowdom because there is all this structure that blown away and
can’t be pointed to by the children of the toplevel elementary elements. So
several different things are happening in those implementations and we
should try to unify them if possible.

BK: there are three categories of things. One uses the shadowdom to its
full effect. It is closest to what the browser can do and is the most
efficient. Then there are ones like the elementary math that are
complicated but can be in the shadowdom so that the lightdom is there and
can be reasoned about. Finally, there are ones like ‘ms’. They need to
disconnect the mutation observer before then make their changes, make the
changes, and then reconnect.

BK: I think we need a plugin manager that handles these three strategies.

NS: that makes sense to me. Maybe there are other styles at there.

NS: what about mirroring the children elements into the shadowdom like what
happens with elementary math.

NS: Are there examples out there where people have more complicated
examples than just one element and no children.

BK: Fred’s latex example is maybe such an example.

NS: But that has no structured content.

BK: there's only the case that you hit the exact sweet spot of your
elements. Children are like DOM representations into something deeper.
There’s only that and not that.

BK: you can’t observe the children, you can only observe the content.

NS: the thing I was thinking about is that for accessibility is that you
have a carry in the elementary math and you want to point to that and say,
“I want to highlight that carry”. But there is nothing that connects that
carry with what is in the shadowdom.

BK: I don’t think we can do this, but maybe there is a way. Maybe something
react-like thing.

NS: If someone changed the background color of a carry, the polyfill could
carry that background color into the color. Maybe a faithful polyfill would
do that if the lightdom.

BK: Let’s say we have a media query and change the orientation of the
phone. How will you know. Or light theme or dark theme changes due to the
time of day change. We don’t have the insights we need into all the
changes. That’s why we have resize observers. If you hook into the
previously unobservable deep aspects...

BK: That doesn’t mean we can’t figure something out. Let’s create a task
force, have the discussion and come up with a documented resolution.

NS: Who’s willing to do this?

Members: BK, NS, RB. Ask Fred.

NS: If anyone else wants to join, send me email.

Long term strategy

   -

   in an ideal world (but one that still requires polyfills), what would we
   like them to look like?
   -

   what "asks" do we have of other committees so that we can get to the
   ideal world

NS: one problem is that you can only do a shadowdom on certain elements,
but that doesn’t allow shadowdom on mathml elements.

NS: park until the task force comes up with recommendations.

BK: MathJax solves the full problem, but doesn’t use core. Need to wait for
DOM to be available to use a polyfill.

NS: what do existing polyfill do

BK: they tend to use feature detection, but also need to figure what the
page really needs.

DC: there are different use cases. I have tons of pages, but I generate
them every night so I can rewrite them to use core.

BK: I think that will be common. People use MathJax. Maybe 60% of the time
MathML core will work. But there are alot of people like David, they can
change things.

NS: There is a tool chain that will take a while to change.

BK: ...

NS: I doubt people will use core until it is all browsers. Maybe they could
do feature detection.

BM: Everyone has some stuff at the top of the page that calls MathJax or
checks the browser. Maybe a better way to think of it as “failure sniffing”.

NS: Not sure how that is any different from checking the DOM because how
else would you know it wasn’t handled?

NS: People who use MathJax now have to wait. With core, hopefully most
stuff renders right away and the polyfills will fix up a few things
slightly later on. That might not be too bad.


NS: Topics for next week?

BK: DOM Core level 1? Currently we have limited developer resources and
some things just won’t get into the first implementation. We should think
about what comes next -- what is level 2. Other groups do this. Let’s go
through the issues and see if we can decide on what level they will be.