Minutes: MathML Core meeting, 1 June

MathML Core Meeting of June 1, 2020

Attendees:

   -

   David Carisle
   -

   Neil Soiffer
   -

   Brian Kardell
   -

   Murray Sargent
   -

   Rob Buis
   -

   Bruce Miller
   -

   Patrick Ion



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

The meeting was recorded:

https://benetech.zoom.us/rec/share/psNeJeqt-HNJZaP87nPNWYEmOJ_OX6a81ihKqaBYyU7QaF7mg_7JtJp4wwpGjXue
(Access Password: 4w#hQ+@j)

Minimal notes today. Listen to the recording if you want details.
IssuesDefine what happens with edge cases of RadicalKernBeforeDegree and
RadicalKernAfterDegree: #213
<https://github.com/mathml-refresh/mathml/issues/213>

Resolved: do as proposed

CSS specificity of mapped attributes (#215
<https://github.com/mathml-refresh/mathml/issues/215>) : use HTML wording
for mapped attributes

Resolved: treat mapped attributes as presentational hints so the CSS wins

Interpretation of new display: math/inline-math and compatibility with
block/inline ( #214 <https://github.com/mathml-refresh/mathml/issues/214>)

Didn’t get to this

What goes where

The basic agenda is about what is going to go into the first version of
MathML Core.

We have already made a large number of decisions about what is not in core.
So we will start with a review of that.

   -

   Neil has written up a summary of the polyfills/transforms/shims that
   need to be written
   <https://github.com/mathml-refresh/mathml-polyfills/wiki/MathML-Polyfill-Task-Force-Guidelines>
   -

   Demo of some of the transforms in action that Neil, Brian, and Rob have
   worked on

There are several issues open about things that would be good to be in Core
but due to time/money/interest are at risk for being in "Core Level 1" (or
"Core V1" or ...). We will go over these in the meeting and see whether
they really need to be in Level 1, can be pushed to Level 2 (and likely
documented as potential level 2 features), or whether they should be pushed
all the way back to full for now.
Issues (WIP):

   1.

   MathML Fundamentals

Initial discussion summary:

What we'd like to do is clean up the spec and focus discussions so this is
clearer from both the outside and just for our own discussions and where we
choose to prioritize time.  Effectively, this happens quite a lot in
standards like CSS, where we sort of bite off more than we can chew all at
once.  That's ok, and in fact, it's helpful to think about the whole
picture - but at some point in practice we have to solidify precisely what
is core and what are we asking people to align with specifically and what
can authors expect as a baseline.  There are several categories of things
here -- the most obvious ones are the ones that we just know we can't get
to because there's too much more to do and we have no implementer who is
willing to commit much time to at this point to this until more is solid
and in place.  A kind of typical thing that we do in CSS WG is just levels
-- we tag things as level 2 and maybe start a branch that includes them but
remove them/filter them out from what we are saying is in the spec.  Then
there are things that are less than that - that might be at risk for some
reasons - but a first step is to cleanup the obvious ones or debate whether
they are obvious..

Resolved to do a '.next' or 'level 2' and clean things up.
2.1.7 mathvariant (
https://mathml-refresh.github.io/mathml-core/#the-mathvariant-attribute ).

   -

   We landed support for "normal" and auto italic. A patch is ready for all
   of the rest and it does not seem a problem for Google reviewers. The
   question is on the CSS WG side since there was controversy in the past
   between doing rendering-only (CSS WG people) and exposing character change
   (a11y people). For MathML we want the latter for all but the automatic
   italic on single-char mi. In Chromium/WebKit, text-transform is implemented
   by character change while it is not in Gecko.
   => Proposal: put this feature "at risk"?
   -

   Chancery and Spencerian. This is a new proposal and is blocked on
   Unicode changes and by the previous point.
   #61
   <https://github.com/mathml-refresh/mathml/issues/61>=> Proposal: not in
   first version of core and remove the issue label?

Resolved: make this Level 2 that is waiting on a Unicode way of solving
this.

MS:
https://docs.microsoft.com/en-us/archive/blogs/murrays/unicode-math-calligraphic-alphabets
  This post discusses the need to add a way to distinguish between the two
kinds of :script” math characters. The solution in Unicode will be
discussed in the Unicode Technical Committee.
2.2.3 DOM/JavaScript (
https://mathml-refresh.github.io/mathml-core/#dom-and-javascript ).

   -

   Allow custom elements in the MathML namespace?
   ( #138 <https://github.com/mathml-refresh/mathml/issues/138> )

Resolved: Level 2

   -

   Allow shadow roots of MathML elements?
   (#140 <https://github.com/mathml-refresh/mathml/issues/140>)
   We have interesting experiments in downstream but it will likely be
   blocked on the WHATWG side for a while and so not upstreamed.
   => Proposal: remove them from the first version? Or define them but put
   "at risk" label?
   => Brian's note: We are taking steps in core informed by these goals.
   The full goals are not realizable in core v1 all in one step, they should
   be moved to v2. With v1 in place, they are a considerably more achievable
   next step

Resolved: Level 2

   -

   Custom layout ( #219
   <https://github.com/mathml-refresh/mathml/issues/219>)

Part of CSS, so when that happens, it will happen with MathML. Nothing to
do. Just need display:math.



   -

   Specialize unknown elements to MathMLUnknownElement?
   (#139 <https://github.com/mathml-refresh/mathml/issues/139>)
   I think this is mostly useful for custom elements?
   => Proposal: Follow same decision as previous point.
   => Brian's note: This is alignment of the sort that belongs in v1, it
   would be bad to lose it if we can help it as it helps establish fundamental
   necessary things for v2 next steps. It basically only aligns us with the
   web of even a decade and a half ago.

Resolved: stays in level 1

   -

   HTMLOrSVGElement/ElementCSSInlineStyle
   We definitely want these and they are implemented in all browsers, but
   likely blocked on WHATWG/CSS discussions.
   => Proposal: It seems ok to keep the ISSUE labels.

Resolved: Already shipped in browsers. Add issue label to spec why names in
browsers disagree

   -

   href
   Implemented in WebKit/Gecko and we have a patch for Chromium. However,
   there are many security questions as well as other issues related to
   tabindex or shadow DOM. So we are likely not going to upstream the patch
   for now.
   => Proposal: Put it "at risk"
   => Brian's notes: I think we need this, it seems to make sense to keep
   for v1 even if it might take some time to achieve parity on this though and
   can be 'mostly' polyfilled (like actually polyfilled I think) for practical
   purposes. It definitely would appear to stand in the way of moving some
   things in v2 forward to me, so just logically it feels like it belongs here.

BK needs to resolve the default tabindex issue with Apple folks. The shadow
DOM can’t have elements with href, so something to keep in mind especially
wrt mrow.


Meeting next week.