- From: Rob Buis <rbuis@igalia.com>
- Date: Tue, 11 Feb 2020 10:15:19 +0100
- To: Neil Soiffer <soiffer@alum.mit.edu>, public-mathml4@w3.org
- Message-ID: <9f945075-2f22-3621-0100-981d5ff2830a@igalia.com>
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. >
Received on Tuesday, 11 February 2020 09:15:46 UTC