Chrome Version : 2.0.157.2
URL : http://www.w3.org/Math/testsuite/mml2-
testsuite/TortureTests/Complexity/complex1.xml
Other browsers tested:
Firefox 3: OK
IE 7: OK (MathPlayer)
What steps will reproduce the problem?
1. Open a page with MathML content
What is the expected result?
You should see the correct MathML rendering.
What happens instead?
You see just a few symbol without correct rendering.

This is a bug for almost 4 years in webkit. Can't you, chromium guys, implement this?
Because I don't think they're really working on this @ webkit. And I think it's a
really needed feature in Chromium.
Reading the thread @ bugs.wekbit.org, we could do something like this: mathml to svg.
And SVG could be displayed correctly.
Thanks for reading!

I'm using Chromium to use Google Wave preview (it feels faster and more stable than
with firefox). But I started using Google wave for Collaborate on Math stuff. There is
nice robots there for rendering LaTeX as mathML. Too bad the MathML rendering is so
poor on Chromium....

Well, to be honest, Opera's MathML implementation is quite broken and cannot handle diacritics properly. It is unsuitable for real world applications (tried to use it for my class notes, for which IE/MathPlayer & Firefox worked fine)

Given that Safari 5.1 now supports MathML, I believe we should look into implementing this. Allegedly one of the reasons it hasn't been already is that it has not had a security audit. Marked it for review.

@rschoen - If someone wants to take ownership of landing MathML then they can file a feature metabug and work through any changes needed to land it (including what I would anticipate to be a large number of security crashes). However, unless someone antes up for the work it's not going to happen on its own.

So this bug seems to be just about enabling MathML parsing from comment 9 onward, but for displaying MathML you might – depending on the platform targeted – also need to think about font support, i.e. about whether you will ship with the STIX/XITS fonts on e.g. Windows (BTW which are now included in OS X 10.7 because of Safari's MathML support I would guess).

I explained on comment #17 what's preventing MathML from being enabled. Simply put, someone needs to take ownership of the feature and get it to a state where it's demonstrated stable and safe enough to ship.

Concerning comment #17, does the remark about potentially "a large number of security crashes" still have any validity whatsoever? Does Apple do that much less testing of the code they use than Google? Not to mention that the MathML code is out in open for a year now.

Are you volunteering and do you have the necessary expertise to do the work? If not, I don't see that your comments are contributing anything useful at this stage. We have an obligation to our users to meet a minimum bar before enabling a feature. No amount of complaining on this bug is a substitute for meeting that obligation.

FYI, Dave Barton is working on Webkit's MathML implementation and is concentrating his effort on fixing the most important bugs that could prevent passing security review. People who are really interested in seeing this bug fixed should follow his work on Webkit's bugzilla and possibly help him.
about comment 24: the two MathML projects mentioned were just proposals from Mozilla. Finally one student was accepted (for a different MathML project).

The previously heavily criticized Webkit implementation has improved quite a lot since 2013: https://webkit.org/blog/6803/improvements-in-mathml-rendering/
Thanks goes out to Frédéric Wang and the other people working on it or arguing for it, I hope Blink will be their next target (and once Blink has MathML, has Microsoft will have to follow suit now that they made it an official stance that Edge has to be on-par with Chrome + they probably need it for better EPUB support).

Ojan/Justin, thoughts on this bug after #44? Predictability program has set an OKR to gain traction on the top 50 starred bugs this quarter: either by closing them, stating what milestone the change will ship, or setting a NextAction date so that we know when to check back in.

#48 My view is that one can very close with plain CSS -- no javascript -- and it can only get better as CSS is developed further. Implementation of CSS flexible boxes added quite a lot of value that, I think, was not available in 2011-2012. In my talk at TUG 2014 I showed examples, e.g.,
http://www.albany.edu/~hammond/presentations/tug2014/gamma-lm.xml
of math rendering using only CSS (actually, a different XML markup, but Frederic Wang has written corresponding CSS for MathML). In the write-up of the talk for Tugboat I made comments about my wishes for the development of CSS. Those ideas are NOT specific to the needs of math.
For more: http://www.albany.edu/~hammond/presentations/tug2014/

#49 how accessible is that XML? We rely on MathML for accessible (for users with disabilities using assistive tech) math, so students using AT are currently restricted to supporting browsers or whoever can run MathJax (which sometimes hangs/crashes pages with many complex equations (esp on phones) and does not accurately display some types of very complex equations, resulting in us rendering images of math (which don't scale) with a hidden MathML fallback as a sort of alt text).
I like the idea of being able to turn LaTeX into MathML/whatever and styled with CSS, so long as the whatever can read sensibly to screen readers and scales nicely with magnification. I don't think I can hope for speech support :(
The more browsers support math, the more choice our end-users have in which browser they can use to consume our content.

#50 "how accessible is that XML?"
AFAIK nothing has been done to tie it to access-related software. The CSS provided with the example is entirely visual. The idea with LaTeX profiles,
http://www.albany.edu/~hammond/presentations/Tug2010/, is that if a community with specific access concerns -- or other specialized concerns -- has its own ideal XML document type, it should be possible to provide reliable automatic translation from a LaTeX profile to that XML document type.

Personally, I think supporting a standard makes sense from an access point
of view, because then screen readers only have a single standard to
implement, and don't have to work around workarounds that people have put
in place.

While rendering MathML via CSS might work, it isn't the same as native
support. It also requires that one learns another library or language, or
use sometimes complicated hack to get it to do what you want. Supporting a
standard simplified the process and lowers the barrier to entry, whilst
simultaneously making sure that mathematical equations can be rendered
correctly in multiple places - without having to convert from one format to
another.
On 15 Feb 2017 3:18 am, "gel… via monorail" <monorail+v2.4120037860@
chromium.org> wrote:

eae@ We're trying to understand the plan for all top-starred bugs. When you say "done in a maintainable way", are you implying that this is perhaps blocked on LayoutNG (or maybe custom layout)?
I'm just hoping that we can mark this bug blocked on some other work and set a Next-Action date for when we should check back in on that work.