Minutes: MathML core meeting Aug 31, 2020

MathML Core Meeting of August 31, 2020

Attendees:

   -

   Neil Soiffer
   -

   Brian Kardell
   -

   Bruce Miller
   -

   Rob Buis
   -

   Patrick Ion
   -

   Louis Maher


Regrets:

   -

   David Carlisle
   -

   Murray Sargent




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

The meeting was recorded:
https://benetech.zoom.us/rec/share/yZ1oKIvrqk5OT4HL73ODffM-G9y1T6a81iUWr6cMnRybaw-bFLz21KoLhcmUKoco
Passcode: wukygG7% (meeting starts about 5 minutes in)

Update on Chrome Progress

RB: Started operator things, it's a big amount with a lot of challenges,
big patches have to be broken up. Last week the big one was the operator
dictionary - that was 2 or 3 patches on its own.  Next will be movable
limits, and then slowly we'll try to handle the other properties, I expect
stretchy will be the last one.

NS: I would expect in terms of visible changes, accent will be the big one

RB: I expect lspace/rspace is next.

NS: Do you know what version of the dictionary you used

RB: We used what is currently in the spec, the compact form.

NS: Yeah but I think David generates that and I'm not sure when it was done
last

RB: But what would change?

NS: There were probably a few hundred changes a few weeks back.There are
more coming. I think a dozen or so glyphs will be removed.

NS: I'm really looking forward to seeing lspace/rspace and accents getting
in there.  They should be relatively easy and make a big difference in the
appearance.
TPAC Breakout Session

What groups/people should be invited/targeted?

BK: The charter lists several groups that we should liaise with.

NS: Can you reach out to individual people you think are important?

BK: Ok.

NS: I’ll submit a proposal in a week or so when they ask for them.

MathML WG charter items
<https://docs.google.com/document/d/1W-oYUbOMueaqb3KFSWkjWVBwR6AzSEBizHwQhvSwfDc/edit>Volunteers
to be Charter Editors?

NS: We have Neil, Patrick, and Brian said he would help out.
Decision criteria for what is in core and what isn'tHow do we decide what
goes into core?Does the that decision criteria need to go into the charter
somewhere?

BK: We should go with WhatWG decision process where implementers have a
veto and two statements of support. Should have two major implementations.

BK: Example is errors. Chrome, Firefox, and Safari all do it differently.
There needs to be agreement between at least two what is right. Doesn’t
need to be implemented at the moment.

PI: … consensus not benevolent dictator…

BK: ultimately they have a veto vote because they are the implementers.

BM: What if two accept it.

BK: if the model is interoperability, then that is it.

BK: it is not about full implementation, it is about intent to support.

PI: the group can vote for something that implementers don’t think is a
good thing, not that I recommend it.

NS: the company doesn’t make a statement, but individuals do.

BK: there are position statements, although the situation is more
complicated with Apple.

NS: in the past, there has been indifference towards MathML. How do we get
statements of support

BK: they are interested in core. I expect they will join the WG. But they
are busy.

BK: so it goes to them and they have some finite window to oppose and also
vendors supporting it.

PI: Can we formalize this rule? So three companies have a veto.

BM: We want everyone to be motivated to have a core spec. We want to have
everyone striving for an implementation. We don’t want it to be “I don’t
like this, therefore I veto it”.

PI: In the past, the Math WG was all motivated to make math on the web. No
one had a vested interest in preserving their implementation/way of doing
things. If we get too specific, we could end up being dysfunctional and not
able to get things done. That means taking a vote.

BK: We need a reality check unless we have agreement from browsers.

NS: who speaks for the company? Sometimes there is a squeaky wheel that
doesn’t necessarily represent the group.

BK: the squeaky wheel is often the person willing to do the work.

BK: Fred wants to avoid the mistakes of the past where people do work but
it doesn’t get accepted by the browsers.

BM: If we had started with MathML 3, and applied this approach, would we
get to where we are now with core? In this process, if everyone would have
a veto for removing a feature, what would we have?

BM: It seems like a waste of time for us on the call if the browser makers
make the call.

PI: If you look at the WhatWG spec, that isn’t what it says.

BK: If you want to do a pull request, you will get a template that says
these people are supportive and none are opposed.

BK: https://github.com/whatwg/html/pull/5841.

PI: It says that in areas of conflict, the editor will try to go to
significant effort to resolve the conflict.

PI: I think in the MathML Core it make sense to specify what it means to
add a new feature

PI: We should add something about the prime role of major browser makers.
It should go into the definition of core.

BK: I think it is about decisions. It isn’t about the whole spec.

NS: we need specifics. If we don’t hear in some specific period from the
three browsers, we could say it is out. But we need some end period.

BK: 30 working days sounds ok.

BK: It is really about the PR on the spec

NS: So we should say that we need to get two out of three of Apple, Google,
and Mozilla review the spec change.

BM: I’d prefer to keep things less formal if everyone is motivated to get
the best math that is interoperable. I fear that if it becomes vetoable

BK: But it is vetoable.

BM: But if currently it is only Google indirectly participating, and none
of the others are.

BK: That’s a misread -- we are reaching out to others.

BM: How does this work in general. Are you going to report back about what
others say.

BK: They would have to agree to the PR.

BM: But that means they need to be formally involved.

BK: But to implement it, they need to be involved.

BK: I’ll write something down and then we can review.