- From: Frédéric Wang <fwang@igalia.com>
- Date: Tue, 14 Jan 2020 11:54:52 +0100
- To: public-mathml4@w3.org
- Message-ID: <3c195f06-b9a0-b547-6b0e-3615f5455114@igalia.com>
Hi, I don't think MathMLCore is going to be listed in that menu. However, you should be able to turn it on via the "Experimental Web Platform features" flag. Alternatively, I believe one can use command line switches --enable-experimental-web-platform-features or --enable-blink-features=MathMLCore. For details: https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md On 14/01/2020 10:02, Rob Buis wrote: > > Hi, > > Regarding my action point, I downloaded Google Chrome Canary for OS X, > version 81.0.4027.0. Using chrome://flags you can can see the > experimental flags and MathML is not listed there. I think this is > best for now as the implementation has just started, but once the > implementation is reasonable we will probably want to offer Canary > versions, so at some point we should ask Google how/when MathML would > get enabled in Canary builds. > > Regards, > > Rob. > > On 1/14/20 12:02 AM, Neil Soiffer wrote: >> >> 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. >> -- Frédéric Wang
Received on Tuesday, 14 January 2020 10:55:12 UTC