Re: Minutes: MathML core meeting on 10/2/20

Glad someone is reading the minutes -- Brian and my work for scribing isn't
for nought :-)

Oddly, the google doc has FW and I just did a copy/paste from the google
doc into the mail. I don't know how those FWs got changed to FMs. I hope
there aren't any other changes.

    Neil




On Tue, Feb 11, 2020 at 1:15 AM Rob Buis <rbuis@igalia.com> wrote:

> Hi,
>
> Sorry, I had to leave midway for something urgent. Reading then notes, who
> is FM? Should it be FW?
>
> Regards,
>
> Rob.
> On 2/10/20 11:23 PM, Neil Soiffer wrote:
>
> 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.
>
>