Minutes: MathML core meeting on 10/2/20

MathML Core Meeting of Feb 10, 2020

Thanks to Brian for helping with the notes

Attendees:

   -

   Fred Wang
   -

   Bruce Miller
   -

   Brian Kardell
   -

   David Carisle
   -

   Neil Soiffer
   -

   Murray Sargent
   -

   Rob Buis
   -

   Patrick Ion
   -

   Emilio Cobos (joined for link conversation)


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



The meeting was recorded:
https://benetech.zoom.us/rec/share/2OZYIZ_e6jNOBc-Sr2jxcbAvMaDvT6a81CEWq6ENxR3GeHub_TDYJl42hlAWAuqL

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

NS: much discussion over the last week via the issue tracker. Bruce, can
you catch everyone up?

BM: We agreed that it was almost equivalent to an mrow with the num/denom
shift by 0.5em or some similar amount. Could use “/”, but doesn’t pick up
linethickness.

NS: linethickness in regular fractions is helpful in nested fractions - you
would never do that with a beveled fraction.  I have no problem dropping
that

BM: It's certainly not the intended use case - the intended use is ratios
of numbers or...something of that nature

NS: One of the main use cases I think is you have some inline math and it's
a little more complex maybe than just a slash and you want to call it out a
little more - you'd use a beveled fraction, but those have to be pretty
simple or it doesn't make sense to keep it inline.

BM: If you stretch it, you start giving it really big things you start to
see quirks in FF and MathJax - trying to interpret the vagaries of the
spec… that's why I thought maybe we could say something about the
equivalence in the spec

NS: Fred, you were against putting it in the spec because it was vague, but
it has been that way for all the elements -- we need to nail it down for
core. What are the issues against defining it because that is the goal of
core

FW: We would have to clearly define how the layout would be and the easy
description given is inadequate… It's just not quite clear how we would
resolve these things. If we do something in core we are supposed to take
these parameters into account. There are still many questions about how we
would do it

NS: I agree core should be used for common things and things that we can
write clear specifications for.  But I'm also concerned for the spec as a
whole - my worry is that there is a polyfill that intercepts every fraction
to see if there is a beveled fraction in it.  I don't entirely understand
how we can put this into something easily.

BM: This is also a concern I have - we haven't specified how the polyfills
are to be used and whose responsibility these things are… this could become
pretty quickly unbearable.

FW: I don't know that we have a clear answer to this, the one thing is that
the blocker isn't on all content.

DC: There's no kind of natural markup for this - if you want to just put
your documents on the web in core without the polyfil, you have to write
some very unnatural markup.

BM: It still is sort of the same thing

FW: Also, another thought I had about accessibility -- if we introduce
beveled we need some specific stuff about it for the accessibility tree if
you want to read it differently.

NS: If you were to use just a regular slash, you would put parens to
indicate the numerator and denominator.. I think that might be relevant for
accessibility.

FW: If you make it mpadded, the native accessibility tree will be the same
as mrow…

NS: mpadded has no semantic meaning, you wouldn't say open paren, close
paren anytime you saw an mpadded.

FW: It is an mrow, so it is a group

NS: Yeah but it doesn't _mean_ anything

FW: It means it is a group, at least - that isn't nothing

NS: It is basically the same as a div or a span

FW: If you just have a fraction it will not know it is a slash

NS: You know it is a fraction

FW: Right - you want to know if it is a slash or a fraction - if you are
actually saying there is a difference?

NS: It really is treated as a normal fraction.  I think that is actually an
argument as to why telling people to use mpadded is the wrong solution;
also a problem for a polyfill.

BM: My proposed solution does wrap it in an mrow

NS: but that is like saying I wrapped it in a div

FW: but you can have rules to make sense of it

MS: If you are doing a beveled fraction you should be using mfrac

NS: It's just a presentation issue.. Unless we start adding -- which we
could -- a mathrole to mrow around the whole thing or something…

BM: The mrow is not ignorable, entirely.  I thought that is kind of its
point.

FW: With mrow you have the ability to navigate between them

NS: mathplayer and mathjax tools … ? …

BM: I am a little surprised about the interpretation of mrows here. Mrow is
semantically useful (some times).

NS: I know for MathPlayer we never throw away a mrow, but we have to infer
them because most tools don't put them in.  To get a good pattern for
speech you need something predictable on this.

FW: (recaps BM's proposal)... if we want to go back to mfrac, I'm not sure
which we want to do… But we need to decide.

NS: I don't think a user could do that - it either has to be a polyfill or
in core because a user doesn't know the height.  If there is real depth -
if you had a subscripted quantity, I think you want this to shift up the
baseline. I think it would shift more than half an em - you need the offset
to be the depth + half an em

FW: In mathml3, sure -- in mathml-core… eh…

NS: I think we can't resolve this this week..

FW: The reason I brought this up is that we are upstreaming mfrac and I
wanted to have a clean spec.  The only issue that was remaining was this
issue about what to do with beveled. I guess we can't decide yet.

NS: I was going to write a polyfill… but I didn't get to it.  Let's move
on..

BM: One last thought: I am kind of on the fence as to whether this is that
important.  It appeals to me but what worries me slightly on 'what is
important enough' and more about polyfills.

BK: A related thing -- knowing which polyfill to use is true of the rest of
the web platform. I like that the CG has a plan and a goal to figure out
polyfills.


Operator dictionary update? #87
<https://github.com/mathml-refresh/mathml/issues/87>

NS: I made progress this… I think there's about 200 changes or so, I'm
hoping DC can review.

DC: I can review them and merge them

NS: We can talk/coordinate offline - I have some questions about building
the spec locally.

Links on elements: #125
<https://github.com/mathml-refresh/mathml/issues/125>, related  #139
<https://github.com/mathml-refresh/mathml/issues/139>

FW: What I understood from Boris is that there is a generic MathML element
class and so all the logic has to be under that class, so more memory and
more checks. There might be some ways to make it faster.

EC: Make sure you know the tradeoffs you are making.

BK: I tried to list out the special things that are special about links on
#125. So things like links need a tabindex=0 even if they don’t have a
link. Support rel with all the notations.

BK: also means can’t have shadow dom because there are security situations.

EC: I don’t think SVG elements don’t do some of them. But the point you
make about Shadow DOM is true.

[discussion of tabindex values for various elements]

FM: the way it is done in the spec is that if there is a link, it is 0
otherwise, -1

BK: I don’t think that is right.

FM: If you have an ‘a’ with an invalid href it still has a tabindex=0?

BK: Yes, but not focusable. The details are a nightmare.

FM: A separate <a> makes things more consistent with HTML.

BK: Having all MathML elements support href is a really bad idea. Moving to
token and mrow is better, but still a problem.

BM: we use href on token elements very heavily. There are times when I
wanted href elsewhere, such as an embellished operator. Nested links would
be a problem.

BK: True for HTML in token elements.

NS: You machine generate them, so is that a problem?

BM: I’d have to rewrite a chunk of code

BK: could be done in Javascript (catch onclick). See polyfill example in
issue.

DC: we could do all of MathML in JS…

BK: but this isn’t rendering

DC: it makes MathML as a language looks incoherent -- “a” doesn’t match
other naming

EC: can’t color links with JS

DC: the priority is to get the implementations accepted, but it does make
the MathML look back.

FW: token elements and mrow are the most used so I’m not sure this is a
simplification

BM: we have links on virtually every token element, so I would think
putting JS would be performance problem.

DC: we do also, and having ‘-1’ has to be an mrow, so we really need it so
negative integers can be linked.

EC: token elements don’t have any special DOM rendering, so it seems
reasonable to allow it on token and mrow.

BK: seems like we can reasonably say token elements and mrow. It means the
one generic container we won’t be able to gain a shadow DOM. Unknown MathML
could render as an mrow, that wouldn’t be affected.

NS: so we need a subclass of MathMLElement that is linkable?

FM: we don’t have anything specific for links?

BK: linky things have lots of things.

NS: I thought someone said there is a class that needs to be mixed in for
links

EC: In gecko, it is only used for ‘a’ and ‘area’.

BK: I found some IDL before that had some additional properties. Still
looking for it…

BK: … contains target, refer policy, …

BK: Anna seems to have done a lot of work recently to clean this all up. I
don’t know if the intent is to get the browsers to be all similar or not.
https://www.w3.org/TR/SVG2/linking.html#InterfaceSVGAElement

EC: If this work was done for consistency, then all browsers should pick it
up. But I haven’t seen it in bugzilla.

(some implementation discussion about that work)

FM: I think we need a subclass

EC: Maybe MathMLLinkableElement?

BK: sounds good. We will talk with Anna to see what is going on and try and
get this all working.

FW: what about google folks? Should contact people working it in Chromium.

BK: Ok. Let’s start with Anna.

BK: If we have href, it needs to support ‘rel’, etc.

EC: Agreed. We need to figure out what the right thing for MathML should be.

FW: MathML 3 supports xlink, but we want to deprecate it.

FW: We need to wait for feedback from google

BK: but we have a coherent direction


Meeting next week.