[snip] > More about compatibility: Do you have any idea (guess really) of how > much of existing MathML content will "work" with just MathML Core? Is > it 99%, 90%, 50%, 10%?
In addition to what Fred said about counters investigation, I can add that the MathML Refresh group (that spent about 2 years working toward this and getting it back on a W3C rec track) was very interested in and focused on this question. We did a bunch of research, and we also asked people with significant pools of MathML already to dig into some of it. I guess I can assure you that much effort spent toward finding an interoperable subset that can give us a baseline for rendering the vast majority of content that was actually achievable and yielded acceptable results with 0-little effort for authors. However, it is a somewhat tricky question because, what does it mean to "work" can vary (or maybe better, how does it 'fail'). So, for example, L1 does not include "math links". This turns out to be kind of trickily nested in a whole bunch of related questions that would take some real additional time to answer. Without answering them, you can still put a regular link inside a token element. Given that, if. you load up some older MathML that includes links on the token elements, it will render the math, but not the link. The working group decided that this was the right tradeoff, because for many things, that's the most important part and it wasn't getting done at all - so this is a dramatic improvement already. It fails better. However, with L1 we now also have the tools to include, with very little additional author effort just a little bit of transform or js handlers to make 'work' like a link too (for purposes they care about) until we can move beyond that. So, basically: It's hard to say with authority but the working group itself has been both very cautious and pragmatic here. They definitely understand that even complete interoperability of L1 can't just make all MathML ever written work. They focused on making "the vast majority of stuff great" and making sure things outside that had a decent story too - be that it "failing" in a better way natively or just having a very simple remediation story, etc. On Saturday, June 25, 2022 at 8:09:25 AM UTC-4 fw...@igalia.com wrote: > On 24/06/2022 11:14, Daniel Bratell wrote: > > > > I'm really happy to see this coming along! Awesome work by everyone > > involved! > > > Thanks! > > > > You mentioned fuzzy testing. Do the fuzzing tools have support for > > mathml elements? If not, you should probably add a to-do item to teach > > them. > > > MathML has been there for several years so I do expect (naively?) that > fuzzers have some kind of support already. My understanding is that > fuzzing tools can either generate data or "shuffle" from existing input. > For the latter, we have now a bunch of WPT tests with MathML to feed the > fuzzers and I believe these are particularly interesting to cover edge > cases with CSS, JS, etc. For the former, I thought that was the case for > https://github.com/MozillaSecurity/ or https://github.com/renatahodovan/ > but can't find any up-to-date repo for MathML currently, so I agree we > need to work on that. > > > > What is the situation for developers that learn about this and want to > > start using it? Are there good resources for learning how to write > > MathML? I think a feature like this also deserves some attention when > > it lands. Maybe that will happen by itself, or maybe someone needs to > > initiate it. That info should probably also mention initial > > limitations like printing, (multi-column?) and non-Core. > > > Similarly, MathML has been there for a while so there is already a bunch > of resource available about MathML (e.g. MDN to mention the obvious one) > as wellas editors & converters to generate it, polyfills to cover > browser's limitations, etc but I agree they will probably need a refresh > since (1) we implement a core subset (2) we are moving to an extensible > approach based on web technologies (3) there are chrome-specific bugs > like the printing one. > > > More about compatibility: Do you have any idea (guess really) of how > > much of existing MathML content will "work" with just MathML Core? Is > > it 99%, 90%, 50%, 10%? > > > I'm don't have actual values to provide but my guess (hope?) is that > it's between 90-99% of existing MathML content delivered to > Firefox/WebKit (note: they implement more than MathML Core but still not > the full MathML3 spec either). But if you want something more concrete, > regarding features we unshipped from Firefox I have a conversation on > Mozilla's matrix channel where we measured counters for deprecated > MathML3 features between 2020-08-11 and 2020-09-17. Most of them were > returning 0 count and only two of them were returning 1 count... to > compare with the counter for pages using MathML which was several millions! > > -- > Frédéric Wang > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/37dc825f-f336-4af5-abeb-bfd2770861c1n%40chromium.org.
