Minutes: MathML core meeting on 6 April,2020

MathML Core Meeting of April 6, 2020

Attendees:

   -

   David Carisle
   -

   Neil Soiffer
   -

   Brian Kardell
   -

   Bruce Miller
   -

   Rob Buis
   -

   Murray Sargent


Regrets: Patrick Ion



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



The meeting was recorded:
https://benetech.zoom.us/rec/share/2stwdOrSzGdOSM_34kDxdaViAofreaa8hylN_PJczBuO0okX2BGa92kDnTvb0Cx5


href/tabindex update (#125
<https://github.com/mathml-refresh/mathml/issues/125>, #206
<https://github.com/mathml-refresh/mathml/issues/206>) -- Apple and other?
Comments

BK: this will be defined in the AAM. Should work like everything else.
Should look to ARIA and how they map accessible name. Probably that means
“title” is what should be used.

BK: as for apple, have been communicating with Tess. Apple would probably
join MathML effort once we are a WG.

NS: I agree. Assuming ARIA goes through “title”, that seems like the path
of least resistance.

DC: Unless we have good reason not to allow it, seems like the simpler
route.

BK: Title is a global HTML attr, so should be supported in MathML.

NS: not part of MathML 3

BM: I remember leaving it off. I think that we should make a mathml element
with an href as indistinguishable from an ‘a’ as possible.

DC: It is useful to be on any element. I use it at NAG for tooltips. Works
in Firefox.

RB: Here’s the title attribute:
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/title

BK: see https://w3c.github.io/svg-aam/#mapping_additional_nd as an
example.  It should be like this, I think.  There is also
https://w3c.github.io/accname/#terminology which might cover this if we
just add title.  The basic idea is we should not specify anything in core
regarding accessible names, if and only if there is a hole remaining here
then we should file an issue with
https://w3c.github.io/mathml-aam/#mathml-attribute-mappings which is where
this hole would be filled.


Resolved: we should add “title” to all MathML elements to match HTML.

BK: we should review the parity of global attrs in SVG and MathML, and
maybe consider adding other HTML global attrs. I’ll take that on.

Action Item: BK to work on the list
https://github.com/mathml-refresh/mathml/issues/207




largeop ascent/descent when using a glyph assembly: #198
<https://github.com/mathml-refresh/mathml/issues/198> -- update/resolve
based on what Murray found about about what Office does

MS: Here’s an example of what OfficeMath does with stretchy large ops


NS: The issue is what to do when there is no content for the integral to
know height/depth.

BM: seems 0 is appropriate for horizontal stretching. For vertical
stretching, I think we should refer to the non-stretchy char (assuming it
exists), and proportionally stretch it.

MS: In office, we require content

DC: Same is true of TeX

BM: Seems like there are two separate things: whether it is stretchy and
whether you assemble it out of pieces. Seems like stretchy comes before
this issue.

NS: The bottom piece might have a depth, so maybe that should be used. I
have a vague memory that some stretchy pieces were designed that way, but
maybe that was just the Mathematica fonts.

BM: The business of assembling it out of pieces is just an extension of the
base character, so it should be proportional.

NS: FW thinks it is such an edge case, it is not worth much code. Rob, is
it hard?

RB: I would need to look at the code.

BM: Why not always just center it on the math axis?

NS: That should be easy to do.

RB: I’ll check with FW and see.


We will have a meeting next week.