Minutes: MathML core meeting on 16 March, 2020

Attendees:

   -

   David Carisle
   -

   Neil Soiffer
   -

   Brian Kardell
   -

   Rob Buis
   -

   Bruce Miller
   -

   Murray Sargent



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



The meeting was recorded:
https://zoom.us/rec/play/v5d8f7v-qDw3T4fG4gSDBPB8W9W0fKis1CgZ-_cPmUe2UyMBN1PwYuBENOKAZogJEZ5K943UQpKtnOQh?continueMode=true

tabindex report:

   -

   Neil on experience with screen readers
   -

   Brian on Joanie/Orca

BK: explained the murky state of description for tabindex. The bottom line
is there isn’t a problem for links on math and AT.

BK: rather than 0, the default appears to be -1 in WebKit if href is
missing on a math element. Unlikely to matter, but being weird in the same
way is probably better for MathML.
Implementation Update

RB: fraction support has landed. Still some small bug, but the big chunk
has landed. Needed to add mathstyle property. Put it behind a runtime flag.
This is leading to supporting scriptlevel, etc.

RB: radicals are coming soon. Landing that is made easier because mfrac
already does some of the things that are similar.

NS: seems that FW has landed some things related to OpenType.

RB: yes, laying the groundwork for other things like stretchy chars
Other issuesOperator dictionary update: #87
<https://github.com/mathml-refresh/mathml/issues/87>

NS: Updated to 12.1. David looked at V13.0 which officially lands in May in
thinks only two new characters, both arrows, need to be added to the
operator dictionary.

Try to resolve bevelled fractions: #29
<https://github.com/mathml-refresh/mathml/issues/29>

BM: did an update to the issue with lots of examples. Can look so we can
decide what is the right way to do them. I prefer what ‘nicefrac’ does --
it raises the numerator by a small amount, draws the frac stretchy
(actually it doesn’t do it, but should), and then the denominator is drawn
on the baseline.

NS: I will try to add a MathPlayer column or maybe MathType or WIRIS

MS: I’ll add something from Word.

Polyfills #188 <https://github.com/mathml-refresh/mathml/issues/188> -- any
more ideas?

NS: Currently can’t use shadow dom or custom element technology

BK: Not sure if we can get Shadow dom or custom layout technology

BK: Some of the DOM things we are normalizing should help, but the web has
problems. I think changes will take time. There are tricky issues that will
take time to resolve.

BK: Anything we do would end up being a library.

NS: It would be really useful to have some rules that every polyfills play
by the same rules.

BK: So you want a coordinated.

NS: and one that hopefully minimizes damage to the DOM. E.g, the polyfills
could wrap the MathML with a div or maybe a custom element and then all the
changes go in the shadow dom.

BK: There is no good solution for this kind of thing out there. We have to
make our own solution up.

NS: What’s plan B?

BK:  We could have some API that provides guidance on how to write a
polyfill. It is maybe something we could experiment with

NS: I’ll come up with a list of elements/attrs that aren’t in core.

BK: Maybe we end up writing the polyfills a few different ways such as
using custom layout as a demo of how custom layout would be a good
solution. Maybe it would help move custom layout along in general...

BM: This is not a brief solve and and close it issue, it’s a longer term
philosophy about what should be in core and not in core.

BK: Maybe indicate what might be moved to core

NS: Linebreaking is something that is probably hard to do as a polyfill,
but my understanding is that it won’t be in V1 of core.

BK: If we go from nothing can be done in MathML today to a great deal but
not all can be done, that’s a big leap.

Meeting next week. Same time (both US and time change from normal in Europe)