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

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 renderas 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.
>