- From: Neil Soiffer <soiffer@alum.mit.edu>
- Date: Mon, 13 Jan 2020 15:02:55 -0800
- To: public-mathml4@w3.org
- Message-ID: <CAESRWkBNSPLBRX9=fv21qzDCC0K9WFiuxzomp-XHevwi0hNhkg@mail.gmail.com>
MathML Core Meeting of Jan 13, 2020 Thanks to Brian for taking most of the notes. Attendees: - Fred Wang - Bruce Miller - David Carisle - Brian Kardell - Neil Soiffer - Rob Buis - Patrick Ion Regrets - Murray Sargent Agenda: https://github.com/mathml-refresh/mathml/issues/8#issuecomment-573384227 The meeting was recorded: https://benetech.zoom.us/rec/play/7JV8d-mvqmo3EoKQ5QSDCqMtW47vfKis0CIW_6YEyBnkUXgKNwKvY-cUZOIMMsM0IDlQmLLvQ-cOd3DX?continueMode=true Implementation Upstreaming Status update - Rbuis: A lot of time off for holidays.. container patch for math/mrow (the obvious children having things) was upstreamed… That took a really lot of reviews and things, stuff we thought we could do later that we had to do now… Google's fuzzing turned out a bunch of things that we hadn't realized we'd need to handle right away. The lucky thing was we were able to turn things around very quickly and get reviews and comments. We also landed mspace which is needed for the tests and in doing both of these we got a much better foundation with more answers. - NS: Does this mean that the real version of Chrome has this code in it?? - RB: Do you mean can users test this in an official release? - BK: Do we have a flag for MathML? - RB: Yes, it's MathMLCore - BK: Then I assume it would be in canary at least and afaik it will go into releases more or less like normal, yes - and if you enable it it should. It won't be very useful - it will only render things composed of only math/mrow/mspace, more or less. - NS: Sounds like a good productive holiday for you rob.. - RB: Yeah, I will look into whether we can show it is in canary and everything TAG Review: BK: when we had our f2f, the two reviewers weren’t that familiar with MathML and wanted to talk to others. They weren’t that familiar with MathML. Wanted more info in “explainer”. How MathML core works in a very basic manner -- what is MathML at the very base level. BK: over the holidays I went back and forth with Alice Boxhalll ( https://twitter.com/sundress) and she made some comments on that so I will do some more work on the explainer and maybe another document (what is MathML -- elevator pitch?) RB: Who is the other reviewer. BK: Other reviewer is Hadley Beeman (https://twitter.com/hadleybeeman). NS: You might want to look at the intro material in MathML. Elementary Math NS: I added elementary math support, but couldn’t make use of shadow DOM without modify the DOM because can’t shadow MathML elements. BK: This should be a whole topic on it’s own. BK: Houdini custom layout might be a better solution BK: Rob/Fred -- if you had to implement the elementary math, how would you do that? Would you create a shadow DOM? Would you just change the layout without a Shadow DOM RB: I’m not sure BK: It doesn’t seem naturally to break the numbers apart and create a new structure. BK: Shadow DOM is meant to for taking the light DOM and projecting it into the shadow dom via slots. The elementary math is different in that it is splitting up the contents and creating a new structure. NS: Here’s is Brian take with a new element so it’s not quite MathML: https://mathml-examples.glitch.me/elementary.html [note: github version that doesn’t have as many bugs is at https://mathml-refresh.github.io/mathml-polyfills/elem-math/] BK: This would be a good topic all on its own another day probably… This is really just a mechanism for discussion - it is a fork of neil's work that was just illustrating something. FW: Doesn’t this just involve numbers? NS: There are some natural extensions. See https://github.com/mathml-refresh/mathml/issues/181 NS: These include polynomial division, synthetic division, and systems of equations. Maybe a way of dealing with some alignment issues. But this is drifting off topic. Probably something for the general meeting. BK: If we were proposing elementary math today, I’m not sure that we would propose that’s the way we would do elementary math today. I think a custom layout is probably better than using a custom element as in the example. NS: I did this over the holidays so we could have some concrete examples on which to base a discussion. NS: I would like to have use mtable so MathML can be in the table. BK: See if I can summarize. The current state of things is that once our implementation is done. We can’t do anything greater than what you can do today other than lots of things can render. But if you want to polyfill (really just transform), you can do that. The next step is to have the ability to use the Shadow DOM on the MathML elements. That would make mfenced work well. It will keep everything independent; you can reason about the light DOM tree. For that, there’s a different standard that is working its way through. It’s not ready to use, but something to think about and maybe experiment with. BK: in the example, the tree remains the same. Not sure it is that useful since this really doesn’t fit with what Shadow DOM is what to do. FW: maybe use mrow with a table layout on that. BK: that would be cool FW: not sure when that would be ready, but you could then just use CSS. NS: when you say use mrow, you are still talking about breaking the numbers/polynomials into chunks. FW: yes FW: it would be interesting to see support for polynomials and see what turns up with them. Operator Dictionary (David) - any updates on fixing up entries - Make things more consistent and general review & fixup #87 <https://github.com/mathml-refresh/mathml/issues/87> #6 <https://github.com/mathml-refresh/mathml/issues/6> #151 <https://github.com/mathml-refresh/mathml/issues/151> - NS: we have a general rule in the operator dictionary that horizontal arrows have the accent property. But there are arrows that are sort of horizontal but have curves that point up/down, and diagonals ones. Does it make sense to change all the arrows to have accent=”true”. Any feedback? - FW: I want to make the operator more compact. I don’t know if this helps. - NS: It simplifies the decision making property, probably doesn’t change how compact the table. Not really sure. - FW: We could also say none of the arrows are accents. - NS: Definitely used for vectors, etc. - PI: Yes, arrows and harpoons are used. Northwest arrow isn’t out of the question. - FW: Why not make all operators accent by default? - NS: Good question. I can’t think of a reason off the top of my head. - DC: If we drop accent, how bad would that be. - NS: I can’t think of a reason off the top of my head. Scanning through the dictionary, I’m not seeing any problems. - DC: I probably see more MathML than anyone, I don’t think anyone uses that property. - NS: I’ve seen screwed up MathML accents. - DC: If we get the default rule right > 50%, that’s good. - NS: Proposal: think about it and discuss next week and hopefully resolve next week. - FW: I have issue #176 about shrinking the table. I think it might help. - NS: if you look at issue #87, at the top of the list is fraction slash which I think is wrong. I have this longer list of things - inconsistencies I've found about priorities and so on that I haven't submitted yet… I'm unsure how to resolve them and I'd hate to edit the table and have it based on just my own impressions - DC: We have git and I think you should just do it in a branch and we can do a diff - FW: This is only priority? - NS: this is priority and spacing, they tend to want to go together.. .It does affect what Core cares about I think. - DC: I also found some surprising things, I think if we can sort of do staged checkins … - NS: Yeah, I think we can try that - I can break them up into different groups in a branch. There are things where there are like circled versions of a plus, and squared versions, maybe with an equals sign beneath them… I'm not sure - sometimes there are differences, like a cross product, that might make sense to have different spacing and priorities - but… Are others? - PI: Vector spaces for multiplication, for example - DC: There are 3 classifications of spaces in …?.... - NS: Yeah we have 5 classes instead of 3, slightly more nuanced I guess, but it's not like we have a huge number - PI: People will sometimes add spacing around some feature that they wish to call out.. But some of them are really absurd, you don't really need a special spacing classification for them. - PI: You may sometimes want to distinguish… - NS: less than or equal to sit at a different priority, but have a different spacing - B: It would seem a good rule of thumb would be a unicode glyph could be thought of as an embellished operator - NS: I thought that, but it's not _quite_ true. But, I'll check stuff in and then I guess we can argue about it off the call. - B: It at least has the advantage of being somewhat predictable - DC: When we were doing this initially, we didn't even have the fonts. - NS: An empty set is a …? Not an operator - so we can pull that, right? - DC: That is probably true - NS: I think there are things we could pull - PI: I wouldn't bother, in some sense. There are things that are accented stretchy, and so on. - <discussion about what is stretchable> - FW: My proposal was to remove the accent property in the dictionary, can we remove more? Some are duplicative, we have had some discussions before. - FW: Could we remove the accent property from mo all together and just use munder, etc, accentunder, etc? - [PI: You could even drop stretchy as something to specify; as David points out in practice it comes down to a question for the font.] - NS: Did we ever gather any usage stats on whether people were setting accents true/false? - FW: It don't have concrete data that is recent, but I think people are using it, I seem to remember …? Was using it - NS: could we use a polyfill, but that would be moving attrs around in the real DOM. - FW: probably too big a change - NS: I agree. Meeting next week.
Received on Monday, 13 January 2020 23:03:45 UTC