Comments by nonmembers will not trigger notification emails to users who starred this issue. Issue metadata
Sign in to add a comment

Enabling support for MathML 

Issue description*Highlevel description of the change (12 sentences):* MathML is a markup language that can be used inline in HTML documents to give visual appearance to mathematical content. Similar to Latex. *Listing of additions/modifications/changes to API surface (bullet points):*  Exposure of all MathML elements and rendering features.  Additional context (fill in as much as you can, or link to a prior API launch bug with the context): *Link to relevant webkit or crbug:* Master bug about MathML: https://bugs.webkit.org/show_bug.cgi?id=3251 Bug to enable MathML: https://bugs.webkit.org/show_bug.cgi?id=96960 *Link to relevant public standards discussion:* http://www.w3.org/TR/MathML2/ http://www.w3.org/TR/MathML3/ *Support in other browsers (current and expected):* Internet Explorer: No support, future unknown. Firefox: Supported. Safari: Supported. Opera: Partial support. Make sure to fill in any labels with a ?. Feel free to leave other labels at the defaults.
Showing comments 30  129
of 129
Older ›
Well, then open a new bug for it. This here was just about MathML, not all that is necessary for math rendering. Concerning math fonts there's now bug 169662 , another stepping stone for those "literally hundreds of millions of students, scientists, and engineers [that] will want to view mathematics on the web." Anyone interested please star.
Note that MathML has had to be turned off because the code is not yet production ready. We hope to turn it on in some future release. We plan to announce this in the Chrome 25 release notes. See also: https://code.google.com/p/chromium/issues/detail?id=174455 @meh Will there be a chrome flag for the more adventurous? Checked in the latest Chromium Canary on Windows, couldn't find a flag that would enable MathML. Tried by enabling WebKit experimental flag, but MathML wasn't working. Will there be a flag added? Unfortunately MathML was implemented in WebKit as a buildtime flag only (#ifdef). There is no runtime flag for MathML at the moment but adding one is a good idea if you want to file a bug about it. It would be a major step backwards to drop support for Math ML. It needs to be there! Huh, MathML going AWAY in Chrome? Sounds like a bad idea. What is the tradeoff here? #32: "not production ready"? It's not yet perfect, mainly because things like mmultiscripts are not presently handled, but it's good enough to stay there. Without it Chrome will totally fail on some current text/html content. Taking it out would be a giant step backward. It deserves to have somebody paid to maintain and improve it. In fact, I now see that MathML support is gone in the Ubuntu package googlechromebeta. Just so that everyone understands the mess that has been created by this regression, I'm attaching a screenshot.
To summarize the current status of this bug: We'd like to enable MathML in Chrome, but the WebKit code still needs further improvements before we can ship it. Closing this bug to "me too" comments. If you'd like to contact a Chromium project member about this, especially if you're a developer interested in working on improving the code, feel free to email me directly. Issue 176698 has been merged into this issue.
comment #40 is out of date. MathML is not something that we want at this time. We believe the needs of MathML can be sufficiently met by libraries like MathJax and doesn't need to be more directly supported by the platform. In areas where libraries like MathJax are not good enough, we'd love to hear feedback about what APIs we would need to expose so that MathJax, et al, can create an awesome MathML implementation.
The problem with MathJax and other JavaScript libraries is the JavaScript part. It’s not fun to have page reflows on a slow connection, and not everybody necessarily has JavaScript enabled besides. Related discussion (on Mozilla's behalf) here: https://groups.google.com/forum/#!msg/mozilla.dev.platform/96dZw1jXTvM/hkNn65Spf4J It is not only the speed issue that make JavaScript far less than an ideal solution. In page JavaScript references do not stay with the content so for example snippets of a MathJax enabled blog as shown in Google+ fail to render as will any other use of document fragments. // I do wonder how you changed your mind so radically in 9 months. We run a large academic journal site which includes occasional math. The challenge for us with MathJax is that we either: (1) include math on every page on our site, or (2) build a math detector that includes MathJax only when we need it. Neither solution is completely ideal. We're going with (1), but it does mean extra javascript downloads and processing on all our pages, even though most don't actually have math on them. Caching helps, of course, but firstpage views for every user are affected. I'm *really* disappointed to hear this. MathJax isn't a good solution for a number of reasons. First, as noted above, it's slow. In a math heavy page, it can take some time for everything to be rendered. Second, MathJax, including the required fonts, is a huge dependency that needs to be communicated over the net. Third, if you want to view a page that includes math when you're offline, you're out of luck. It is true that MathML is not pleasant to write, but that's not a big issue, since there are good tools for converting TeX math to MathML. TeX inside HTML is problematic anyway, because of differences in escaping rules. This is really a big issue for those who hope to use HTML for serious academic writing. I really don't understand the reasoning of the Chrome dev team. Clearly we are very far from purist reasoning  in the end of the day MathML is part of the HTML5 specification and should hence be supported by any HTML5capable browser. And it's not like MathML is "defective by design" and gives you no choice but to abandon it  adoption is way up with Firefox and MathJaX support and the new introduction to EPUB3. Practical circumstances can motivate delaying Chrome support, or motivate providing it incrementally in an ongoing development effort. But practical arguments such as "a javascript library exists that renders parts of the MathML specification as CSS", can not motivate entirely abandoning Chrome support for MathML. After all, MathJaX does not come bundled with Chrome and MathMLenabled pages that do not explicitly load MathJaX continue to remain broken for Chrome users (while still valid (X)HTML5). If you are claiming that the Chrome team intends to activate MathJaX on all web pages instead of native MathML support, that would be a more understandable, yet still rather silly, course of action. Declaring that Chrome shouldn't support MathML because you could in principle find a JavaScript library instead, is not in any way a meaningful justification (why bother implementing any of HTML5? You could just let some JavaScript library render your SVG via CSS or compile it down to a PNG, and so forth for the other features that don't need security considerations). Chrome goes out of its way to provide a native PDFviewer. At the same time, the ISO 320002 specification is expected to have support for MathML tagging of formulas in PDF documents. Math publishing is moving forward with MathML as its foundation. The reluctance for Chrome MathML support keeps striking me as counterintuitive. Use SVG only for MathJax and you should see significant speed improvements. MathML in Chrome would be nice, but I hardly see it as necessary. I don't condone their position, but I don't think it needs to be priority either. MathJax renders SVGs much slower than it does HTML + CSS for me in Firefox. If Mathjax is a better alternative than MathMl, then may be the Mathjax js, fonts and other dependencies of Mathjax should be included with chrome to minimize load times and make it more efficient. Only that it is not a better alternative, as the good folks at MathJax publically state.... To quote Henri Sivonen: > It's valuable to be able to publish math on the Web in a way that: > 1) does not require sending a JSbased renderer along with the data > 2) participates in linebreaking and reflow > 3) integrates with the patterns of the platform (DOM, Selectors) > 4) can be copied and pasted as math (as opposed to an image) > 5) already works in 2 out of the 4 major Web engines [...] I personally would add 6) that enable rich, mathspecific interactions that make math alive and turn math documents into mathaware applications analogously to gmail google docs for regular documents. These are not or only partially supported by MathJax. I guess we have to ask ourselves what the reasons for leaving out native MathML support in chrome, and the only argument that I see holds any water is "Math is not a market for us". This I see as a legitimate argument, but I think with the increasing adoption of MathML in EPUB3, in Math Websites, blogs, ... which is made possible by the transition technology MathJax, I believe that this is a rather shortsighted argument. I for one do not make chrome my default browser the for one reason that it is deficient on MathML support, and the slowdown of using MathJax outweighs the speed increases I get from faster JS support in chrome. I guess that we will see this more in the future. > then may be the Mathjax js, fonts and other dependencies of Mathjax should be included with chrome to minimize load times and make it more efficient. > Indeed, if chome buys into the argument "Math is not a market" then shipping MathJax as a part of chrome is the best stopgap. #46, I don't think the naysaying protagonist in that other discussion has come anywhere near making his case. I think it would be good to ask the MathJax developers about that. I think they would be able to fix this bug without integrating MathJax to chrome. Ironically, on the MathJax mailing list, we've recently been discussing a problem with MathJax in Chrome that causes some pages to consistently fail in rendering the math. Davide Cervone, the author of MathJax, narrowed things down to cases where an object returns itself when a property is accessed (instead of the value of the property) in certain situations: https://groups.google.com/forum/#!topic/mathjaxusers/CWGx1koV3SU First, thanks for opening comments again on this issue. It is in the top 30 by votes and it seems reasonable to listen users rather than just ignoring any feedback. I'm not sure why people are surprised by this statement since this was the position Ojan gave on his blog after MathML was disabled. And I still continue to interpret the "at this time" as "we do not plan to support native MathML any time soon and we prefer to rely exclusively on MathJax for now" that is they will reconsider that decision in the very long term. Or perhaps I'm wrong and Chrome people just do not want to support MathML natively at all in the future? (MathJax integrated in Chrome as Web Components or something is *not* native support and has essentially the same issues) The only difference since February is that Google's "security concerns" have been fixed in WebKit and so this argument to refuse MathML is no longer valid. However, Ojan's statement on his blog that WebKit's MathML rendering is not good enough compared to MathJax is still valid. Actually, I was surprised when Peter Kasting commented on my blog that they would accept a patch to reland WebKit MathML now that the "security concerns" are fixed. Here is how I personally see the future: * Moritz Schubotz and others have recently done a great job to integrate MathJax serverside in Wikipedia. This will soon provide alternative options for anonymous users like SVG rendering (same as the old raw image but with better rendering quality) or native MathML rendering for browsers that support it. Once MathJax 2.3 is released, I will help Moritz to finish a better integration of MathJax clientside (for example to get HTMLCSS rendering or extended user interface) although this option will still be much slower. This will show a concrete example where native MathML is a big advantage and will contradict the fallacious argument that "native MathML is not used on large Website so not worth implementing". * After that, I'll try to find funds to spend more time on native MathML developments (Gecko and WebKit). I'm aware that there is a lot of work to do on WebKit MathML that can not be done by volunteers or parttime developers only. However there are core WebKit developers interested in helping and I wish other people could provide (not necessarily technical) support too. I'll give more info about that next month. * In the long term, once WebKit has reached a decent MathML quality and/or when we have a professional organization for native MathML developments, then we might consider maintaining a fork of Chrome with MathML support: https://github.com/fredwang/Chromatic#chromatic. To be honest, I think at the moment it is best for Chrome users to just switch to Firefox (with the appropriate math fonts installed). * In a very very long term, Chromium developers might change their mind and integrate WebKit MathML back in Chrome (and drop MathJaxinChrome if they tried that in the meantime) this sucks. In 2010 I gave a talk, where I wanted to mention, that Firefox and Opera have MathML support, and only WebKit browsers lacked it (Trident doesn’t count here). Right before the talk WebKit contributor Nikolas Zimmermann pointed me to the changeset, that _enabled_ it in WebKit and the crowd went Yay! And now, three years later, that not only you just don't switch the flip to enable it, but also drag Opera with you in not supporting maths on the web? That’s a crappy move. Opera devs: You had decent MathML rendering. Pour that knowledge in Blink, please? A use case that particularly suffers from lack of MathML is email :( How do you send somebody an email with formulas such that he can see them nicely? * Linking MathJax is out since email clients block javascript (even if they didn't, offline reading is desired and embedding all of MathJax is out of the question). * Representing math with images is has quality and size mismatch issues; SVG is the only hope. But email clients tend to hide images by default, and SVG support is particularly spotty. [http://conference.createsend.com/screens/r/06A83737A07C505E] * Senderside conversion to HTML+CSS is possible, and perhaps the best option now. But it cannot achieve good quality across readers — the reason MathJax needs to run on the client is that placement & sizing must be adjusted to specific fonts. In the long term, the only sane approach is MathML. It's passive, safe (bugs aside), fast and can be rendered offline. If most browsers would support MathML, it would be easy to allow it in webmail clients, which I hope would then encourage desktop clients to support it. (It's true that webmail sites could skip ahead and use MathJax now, but that's unlikely. Would e.g. Gmail team accept the extra weight — and security review surface — to support a part of html that isn't even well supported by Chrome?)  BTW, security is another reason this is sad. Sites may be loath to execute mathjax on all their pages (at least without a security evaluation). E.g. Github wikis used mathjax, but later disabled them "due to security concerns" [https://github.com/gollum/gollum/issues/288]. In the grand scheme of things it seems better to securely implement MathML in browsers vs every site having to trust a huge JS library. I am *very* disappointed when I read #43. Math is THE universal language, understood by every nation on this world and used to describe and analyse our world in physics, chemistry, biology and even economics. Let me compare the situation to hypothetical one: In my native language, german, we have 'Umlaute': ä ö ü. Two main browers included them already in their charset. All others still have to read something like \ae \oe \ue in their browser. To avoid this, some clever folks have come with a program, that searches for every \ae an replaces it with a tiny image of 'ä' and so on. This only works when being online. And now the suggestion is: No, we don`t implement the 'Umlaute', as the standard suggests, we make the replacement program faster. NO WAY! Being a student of Math and a fan of Chromium/Chrome it breaks my heart that the two cannot come together :(. Dear all I think it is a mistake Google to turn its back to scientific community. Google is here leaving its roots. This will hurt the Chrome OS strategy toward education institutions. It should send a very negative message to so many "sponsors" of Google. My advice is that this decision has to go to the board and to Mister Sundar Pichai. All the best I agree with the comments above. Math is the centerpiece of everything. All major innovations: Physics, Biology, Computer Science, Economics etc. use Math as the universal language. Its important that browsers understand Math natively rather than some through some JavaScript shim like MathJax. Just like search engines and machine learning programs understand words today, they will understand math in the future. For pervasive support of math around us, our browsers should be able to display math natively rather than go through hoops and use an external library. For heavens sake Chrome supports PDF, Unicode out of the box. Wouldn't seeing math equations without using an external library be appropriate? One serious problem I have with mathJax is integrating it in a wysiwyg editor like TinyMCE. I don't mean wysiwygediting the formula, just being able to show it in the editor window and e.g. click on it to edit it's code. The issue is  mathJax is terribly hacky, changing a lot of DOM. So you have to call mathJax outside the editor window in an invisible placeholder and move it  this unfortunately also breaks loads of stuff and noone has been able to create a plugin for an apparently very simple functionality. All working solutions I know load servergenerated images instead. Googling tinymce+mathjax gives you mostly questions and some very buggy, unusable solutions  a lot of people have tried and failed, it's a common use case. In general, using mathJax for anything other than displaying static math in welldefined, fixed environments is incredibly hard. Maybe a solution using mathJax inside the browser would be enough (so there's no DOM changing from the user's point of view and no issues with loading mathjax). @commenter 67: Try fiduswriter.org . We have it working in a contenteditable view without resorting to images. And we are open source (AGPL). However, we need to intercept the caret to make sure it goes the right place  something like 1100 lines just for Chomr. Firefox would require something of similar length. Feel free to study our sourcecode. Also feel free to contact us there or writing to the email list of you have more questions. I should clarify that the MathML security issues were never resolved. We stopped filing new issues because we disabled that code and thus were no longer testing it. However, it was clear that our fuzzers would have continued to regularly identify new security vulnerabilities. From the security perspective, there were simply more fundamental issues in the design and implementation. And there was no one who could commit to the larger refactoring and ongoing bug fixes that would be needed to stabilize the feature. Had we kept it, we would have been left with known dangerous code that had no reliable owners and no clear path to getting it fixed. > I should clarify that the MathML security issues were never resolved. We stopped filing new issues because we disabled that code and thus were no longer testing it. However, it was clear that our fuzzers would have continued to regularly identify new security vulnerabilities. From the security perspective, there were simply more fundamental issues in the design and implementation. And there was no one who could commit to the larger refactoring and ongoing bug fixes that would be needed to stabilize the feature. Had we kept it, we would have been left with known dangerous code that had no reliable owners and no clear path to getting it fixed. This seems pure speculation, given that these issues have been addressed by disabling MathML in Chrome and no one can tell for sure what would have happened otherwise. So I'd prefer to discuss about what is really certain: all the MathML security bugs reported by Google that I'm aware of I've been fixed in WebKit now. Certainly there are other design problems in the MathML code but that's a separate issue. When I mentioned MathJax Consortium's plan to dedicate a bit of resource to help MathML in WebKit, Chromium developers ignored my comment and just dropped the MathML code from Chrome. And when I asked on the WebKit bug entry to tell me what were exactly the vulnerabilities and/or to give test cases, none of the Chrome developers ever replied. So I think you should stop with the security argument ; it certainly made sense when you took the decision to disable MathML but at that point that's totally irrelevant. That said, I agree that WebKit MathML needs improvements and that you are free to decide what your priorities are. And users are free to complain or to switch to a better browser. I have an application where math content is, for various reasons, rendered on the fly in a set of columns within an iframe. With a few hours of experimentation, I was unable to get MathJax working correctly in this context (though I have successfully gotten it working in more standard contexts). Given the my time constraints, I ended up rendering my equations as images and moving on to my next issue. This was a painful choice that resulted in an inferior solution. If Chrome supported MathML, I wouldn't have had to spend any time on the issue and would have obtained a superior result. Do I like the MathML syntax? No, it is ugly and much too verbose. Nevertheless, it is a standard with fairly wide adoption; Chrome should support it. MathML is positioned for good adoption as the defacto standard going forward and reading the original comment, I think we are all in agreement that a MathML processor/renderer is the right way forward. Completely understand the need to cut extraneous or superfluous features but math is fundementel ... MathML is something that should be supported, pls reconsider carefully how Chrome may support it. Would it be possible to implement MathML behind a command line flag that is disabled by default? Then only those who know what they are doing will enable it. I have filed bug #174852 about it. #69, given that the "security issues" you mention are unidentified in this discussion, might you at least indicate what is the category of security issue involved. For example, are you saying that the native MathML support opens a door to writing in the file system of the platform where Chrome is running? Is there a concern that the native MathML support might put Chrome in an infinite loop or cause Chrome to crash? Is it worse than the feature of putting out "e=mc2" for a perfectly valid piece of html5 equivalent to "e=mc^2" in TeX? For better overview I created a procons list, which anyone can edit: http://www.prosvscons.com/lists/611102 I'm mostly interested in MathML for a CEF (Chrome Embedded Framework) application. @fred.wang  There was no speculation on my part. I'm stating facts that are apparent with a reasonable understanding of WebKit/Blink's architecture and the nature of security vulnerabilities that can occur (e.g. en.wikipedia.org/wiki/Dangling_pointer). The MathML code had fundamental architectural issues (e.g. modifying the render tree during layout) that are guaranteed to introduce security vulnerabilities. Until those underlying issues were fixed, our fuzzing infrastructure was just going to continue identifying new triggers for the vulnerabilities. Assuming that those issues were resolved, there was still the concern of ongoing ownership. New vulnerabilities will be found in code of any complexity over time, either because code around it changes enough to introduce new bugs or simply that our understanding and detection methods improve such that we unearth new instances or whole new classes of vulnerabilities. That's why we don't ship code in Chrome unless we have an owner who is responsible for its long term viability. Anything less would be grossly irresponsible. With respect to past offers of engineering assistance, the relevant bugs are restricted to protect browsers shipping the vulnerable code. However, any of the engineers working on MathML could have given you access, so I would suggest approaching them directly. Although, fixing the issues would require a significant time investment and deep knowledge of WebKit/Blink layout and rendering. To put it in context, several engineering weeks had already been spent trying to resolve the security issues before we were forced to disable the code. Beyond that, I can't speak to why the Blink project isn't currently interested in supporting MathML (because I honestly don't know). I can only provide the facts I have regarding the very real security issues. Could you please clarify where you stand between "it's not a priority for us but we'd accept contributions of _sufficient_ quality" to "we don't want Chrome to support it, ever"? #69 sounds like the former, understandable, but #43 came across kinda like the latter, which is a harsh position to take. #76, You wrote: "The MathML code had fundamental architectural issues (e.g. modifying the render tree during layout) that are guaranteed to introduce security vulnerabilities." I've not seen the code. But... We're talking about code that ships with the browser, not something like imported javascript. The code is there for the purpose of rendering the contents inside <math> elements. So, for example, where the markup is "<mrow><mi>e</mi><mo>=</mo><mi>m</mi><msup><mi>c</mi><mn>2</mn></msup></mrow>", and the rendering is now coming out as "e=mc2" (all mathml elements ignored), are you saying it's a security issue that the plain rendering of cdata is modified? Surely you must mean something else. Could you clarify. For example, is the code writing in dangerous ways outside of the area of the <math> element?
@gellmu  The gist is that WebKit/Blink assumes certain invariants in how major data structures are managed in memory. As an example, one of the invariants violated by MathML is that the render tree should not be modified during the layout phase. This invariant is necessary because various components in layout store pointers to objects in the render tree, and if the tree is modified during layout those pointers can wind up referencing invalid memory locations. Typically this results in a condition known as a dangling/stale pointer vulnerability (aka. useafterfree) <http://cwe.mitre.org/data/definitions/416.html>. Stale pointer vulnerabilities are generally rated as highseverity on Chrome's scale <http://www.chromium.org/developers/severityguidelines>. A properly built exploit of one of these vulnerabilities would allow an attacker to execute arbitrary code inside the renderer process, bypass all originbased security restrictions, and perform escalation attacks to potentially break out of Chrome's sandbox. In an unsandboxed Chromiumbased browser, the exploit would simply be able to execute arbitrary code at the full privilege of the user launching the browser. @jschuh: Thanks. I am aware about the issues and agree that this made sense from a security point of view. However, we are talking about different things: you are still trying to argue about decisions that took place several months ago when you disabled MathML and you are mentioning things that could potentially have happened, overlooking the work on WebKit side since you created the Blink fork. The point here is that comment 43 says this reasoning is out of date and that a native MathML implementation is not desired by Google ; this contrasts with the official position so far that was "if a volunteer does the job to fix the issues, we might enable MathML again". Since April, I've worked a bit with Martin Robinson to fix bugs in WebKit. The two main design issues with potential stale pointer vulnerabilities, namely preferred widths depend on layout information (https://bugs.webkit.org/show_bug.cgi?id=107353 and others) and render tree is modified during layout (https://bugs.webkit.org/show_bug.cgi?id=57700 and others) as well as one hang that could not be found by a "mixing small DOM trees" fuzzer only (similar to https://github.com/mathjax/MathJax/issues/366) have all be fixed so far. So looking to the future rather than backward, the point is how to find someone who can ensure maintenance and development of the MathML code since using volunteers as "owners" just does not seem reliable or efficient for a core feature of the layout engine. Also, given that I'm now familiar with WebKit and that a couple of WebKit engineers are interested to help improving MathML, the ideal approach is to to continue the work on WebKit and perhaps import it back later in Chromium ; rather than trying to convince Google engineers to invest seriously on native MathML... As Fred has said more than once, the security issue is no longer present, so I don't know why that keeps coming up. The question that has been obliquely raised but never answered by the Chrome team is: why don't you hire someone to work on MathML so that someone does own the code and can fix problems when they come up? Clearly the Chrome team feels SVG is enough of a priority to hire more than one developer to work on it. Why isn't supporting math education in schools by providing a good math browsing experience a priority? Waiting 35 times longer than a native implementation (which for a Wikipedia page can be over 10 seconds delay) falls far short of providing an awesomely good experience. Nor do the other problems that people have pointed out with a JS solution provide an awesomely good experience. Comments like "We believe the needs of MathML can be sufficiently met by libraries like MathJax" show a lack of understanding of what the needs of the math community and math education are. I hope that someday someone in on the Chrome team spends the time to understand what those needs are and addresses them so that innovative math solutions can be part of Chrome. Students are impatient, even at the undergraduate college level. It is important for math to be fully on the same playing field as classical html. I'm extremely disappointed to hear this. Researchers, educators and students have been waiting for a decent way to communicate on the web about technical topics for the better part of twenty years. MathML provides that. Can we please prioritize a feature that actually has, you know, an actual social benefit? Blog post snippets included in other places than the blog itself is a fair point of something lost by providing MathML through a JSlibrary. Although, if such a thing became sufficiently popular, you could imagine key sites like Google search results starting to include a MathML rendering library when the snippet included MathML. The "at this time" bit in my earlier comment was mainly that I'm not saying we'll definitely never implement MathML. If we were the only browser left that didn't implement it, and there were sufficient web content that used MathML, that would certainly change the tradeoffs involved. It's admittedly a chicken and egg problem. Right now performance is our number one priority, not features. Incidentally, the SVG comparison is a good example. We, in fact, do not have even one fulltime engineer working on SVG and almost all the SVG work that we've done has been around security and crash fixes. In the chicken and egg equation, there's considerably more SVG content than MathML (by a couple orders of magnitude at least). #85  Re: "considerably more SVG content than MathML" How are you making this determination? For example, are you seeing the mathml served in application/xml+xhtml ? Are you counting math served via mathjax (which depends on MathML though not on native MathML rendering)? Is the measure of svg limited to svg markup in html (and xhtml) or does it also include imported svg objects? There's a huge amount of math online as PDF not yet in html+mathml because of the chicken and egg issue. When I last checked (January of this year), there was no html+mathml at the Los Alamos/Cornell arXiv (www.arxiv.org). (There was a big project "arXMLiv" devoted to translating the arXiv to html with mathml  http://trac.kwarc.info/arXMLiv/wiki/arXMLivprojectdescription ) Do we want our children to grow up with the impression that math is not important enough to be in web pages? William F Hammond Email: gellmu@gmail.com https://www.facebook.com/william.f.hammond http://www.albany.edu/~hammond/ Re #85: > Right now performance is our number one priority, not features. Viewing http://www.albany.edu/~hammond/demos/Html5/arXiv/Tex4ht/1108.5305.html (mentioned in http://news.cnet.com/83011023_35761085493/googlesubtractsmathmlfromchromeandangermultiplies/), On my machine, Chrome takes 5'30" to display all the math, 4'45" after caching. The same page with native Firefox rendering takes 25". That's an order of magnitude slower in Chrome. The multiplier would be greater if the page didn't have to be served by MathJax, as 1015 seconds is MathJax scanning the page. So Chrome is a dog for pages that use math. You can switch to using SVG. SVG is much faster in Chrome (45"), but the quality of display drops significantly and the math doesn't match the text well. > (MathML content) As for math content on the web... Typical markdown for math in a page uses TeX. MathJax turns this into something like MathML internally for rendering. If there is a native renderer available, MathJax will put MathML into the page. So you should be looking at instances of TeX and MathML if you want to consider the importance of MathML content. MathJax had over 55 million unique visitors a month last spring and has probably grown to over 60 million unique visitors per month in the fall. If those people all used Chrome, that would be 60 million people slowed down by Chrome's lack of native MathML support. Re #85: > Right now performance is our number one priority, not features. Math in Wikipedia articles looks horrible on mobile, because it's rendered as images and scaled improperly, especially for inline math. However, if I switch to using MathJax for rendering it is possible to read the math, but it takes forever to actually show it. This is not what I call great performance. I can't believe native MathML has so low priority. > Although, if such a thing became sufficiently popular, you could imagine key sites like Google search results starting to include a MathML rendering library when the snippet included MathML. > Math in Wikipedia articles looks horrible on mobile, because it's rendered as images and scaled improperly, especially for inline math. However, if I switch to using MathJax for rendering it is possible to read the math, but it takes forever to actually show it. This is not what I call great performance. The experience with MediaWiki people to integrate MathJax was quite instructing about how maintainers of large web sites could react. Although a MediaWiki volunteer has done MathJax clientside rendering for a long time, the MediaWiki have not been quite exciting to make that option the default. See for example http://www.mailarchive.com/wikitechl@lists.wikimedia.org/msg70161.html for the point of view of one MediaWiki developer. The solution that Moritz and others have recently worked on is to use serverside TeXtoMathML and MathMLtoSVG conversions via MathJax+phantomjs ; and this can of course be cached in their data base. So e.g. browsers like Gecko will directly render the MathML and others will use the SVG fallback. This will solve some of the performance and rendering issues perceived by users in future versions of MediaWiki. However that makes the serverside code overly complex and we have to produce and store additional and larger images in the data base, just to work around the lack of native MathML support in browsers that don't support HTML5 very well. I'm really skeptic about the fact that popular sites like Google search results would include the Javascript snippet for MathJax or are likely to rely on complex backend converters. In #86 I said: "When I last checked (January of this year), there was no html+mathml at the Los Alamos/Cornell arXiv (www.arxiv.org)." Since I said that, I have learned that arXiv has begun using html+mathml in the abstracts of its articles around mid October (2013). I have opened an issue to implement MathML image & text fallback: https://code.google.com/p/chromium/issues/detail?id=324764 This will be helpful for some web sites like MDN or Wikipedia. BTW, I have also launched a crowd funding campaign for MathML, as mentioned above: http://www.ulule.com/mathematicsebooks/ This will include improving MathML in WebKit and so might be imported in Blink later. Perhaps I may find time to build Chromium again and try to work on the image/text fallback issue if Chromium developers don't do that in the short term ; but I can't promise ; my priority is on WebKit/Gecko, right now. Just as a backup of the pros vs cons list people contributed to... Pros of native MathML implementation: * It's part of HTML5 * Support for linebreaking in MathML, especially dynamic line breaking as the size of the window or content changes (MathJax doesn't change line breaking when content size changes, and will likely never be able to do linebreaking on inline math). * Ability to modify/query MathML DOM elements as with any other content (this is difficult in MathJax). * Full integration with CSS (MathJax doesn't do this well). * Semantic Math, not just an emulation of what it should look like visually. * Copyable MathML (where the clipboard knows that the data is MathML and therefore can be seamlessly copied/pasted to/from applications like MS Word or Mathematica). * Math in emails? * JS does not need to be enabled. * Faster rendering than with JS. * Integrate math support with no effort on website/webapp. * No extra downloading for JS library (mostly useful on first load). * Hasslefree offline support. Cons of native MathML implementation: * Existing codebase may have security issues. * Can be implemented using 3rd party JS libraries like MathJax. * Adds more code and complication to already existing browser source code. I opened issue #1748952 upon suggestion to enable support for MathML behind a runtime flag, but I was not able to post a comment on the previous issue because commenting was locked. Implementation may be as easy as adding an agent stylesheet. Here's a small proofofconcept I wrote up in CSS3: http://jsfiddle.net/Supuhstar/tB9jm/ > Implementation may be as easy as adding an agent stylesheet. Here's a small proofofconcept I wrote up in CSS3: http://jsfiddle.net/Supuhstar/tB9jm/ That was already experimented in Opera Presto and I have another version here that will be used on MDN: https://github.com/fredwang/mathml.css. However, I don't think you can reach high rendering quality with only CSS stylesheet. Given that one of Google's excuse to remove MathML support was the lowlevel quality of the C++ implementation (which was already much better than Opera's CSS one), that's really unlikely to be accepted. Moreover, I already added a basic UA stylesheet to handle alternate content (https://codereview.chromium.org/138383003) but Blink has some restrictions for UA stylesheets (e.g. universal rules or sibling selectors are forbidden). @#94 That stylesheet looks ok  I would say that something is better than nothing :) Is it possible to edit my own personal user agent stylesheet so that I can add that CSS? Re #95, Tue, Apr 15, 2014 (Did the Opera experiment use CSS3? I don't think I saw that.) Indeed, Fred's mathml.css shows that going to CSS3 helps quite a bit more than CSS2. Nice job! This would seem to give one reason to believe that ultimately native MathML handling can be faster than we have so far known it by relying on the increasingly more powerful versions of CSS in conjunction with the native rendering. Also it would be good if the cascade in CSS were factored into the native rendering so that style sheets of this type would not clash with native rendering in the way that we see now.  Bill How exactly is Chromium "An opensource project to help move the web forward" without MathML? It is an HTML5 standard. Does Chromium have a contingency plan to support mathematical formulae hyperlinking? If Wikipedia implements it people might well drop Chromium/Chrome and go to a professional browser that supports it. Here is an eager bump to this really important and high profile issue. While Chrome and IE refuse to invest in MathML, we now have MathJaX competitors springing to life. KaTeX just started trending: http://khan.github.io/KaTeX/ It is essentially a lightweight MathJaX clone which focuses on rendering the mathematics as quickly as possible, in order to provide better performance for mathheavy pages. Yes, high performance is now one of the big issues being tackled. And, as mentioned earlier in this thread, that is the one obvious aspect where a native browser implementation of MathML rendering would win hands down and would offer math practitioners (from primary school students to Fields medal winners) a high quality experience. I think mediawiki is going to have support for MATHML in it's visual editor sometime soon too  I read this on their weekly tech news a few weeks ago. As a end user, this is frustrating to me. My university websites renders either images or MathML. The images is low resolution to save on bandwidth so clarity can be questionable. MathML does not suffer the same fate but only works on Firefox which means I have to change browsers every time I want to view a MathML site. MathML is now official part of the HTML5 Recommendation. And so reliance on MathJax and it's shim ilk should no longer be the preferential choice, except for interoperability on older, not modern, browsers. http://www.w3.org/blog/news/archives/4167 http://www.w3.org/TR/html5/embeddedcontent0.html#mathml (HTML5 4.7.14) I've written a C library years ago that can render a subset of MathML. I've since abandoned it due to lack of interest from users. You can see the screenshots here: http://reformath.webnode.com/ Please provide some feedback regarding the quality of the rendering. If Google is interested to adopt it, I'm willing to continue improving it, including support for OpenType Math Tables. It Would Be Great If Google Chrome Supported MathML MathML is now an ISO/IEC standard: http://www.w3.org/2015/06/mathmlpas.html.en Time to get to the 21st century Google! As a former educator and a data scientist who writes documentation for the web, Chrome's lack of support for MathML is simply unbelievable. It's been a standard for over a decade and has been ISO/IEC standard for 3 months. Firefox/Safari/Opera all have supported MathML for years. Chrome is the same camp as IE. IE! Google, do you really want your browser to be the next IE6 of the web? A ubiquitous, problematic browser that forces developers to add shims and workarounds? MathML may not be an issue of concern to the general webviewing public, but to those of us who use it daily, the Chrome team's indifference is a black eye to Google's brand. I had to go research this extensively because I couldn't believe it, Chrome has no support for MathML! Very very odd! I am ready to donate to Google so they can hire someone to fix the "security" issues with MathML! As editor of the weekly "Varsity Math" column in the Wall Street Journal, I can say that the lack of Chrome support for MathML has certainly caused us difficulty, and slow page loading, in publishing that column. The National Museum of Mathematics would be able to improve its web outreach if Chrome supported MathML. If those responsible for the roadmap for Chrome read this issue tracker, please put MathML back on that roadmap. Thank you. Chrome team, you should be ashamed of yourself. Can someone please justify this decision to not put any effort on this feature for 3 years? Even when effort was given, you didn't even pay the people that worked on mathml... MathJax has done a great job, but as a mathjax team member has said multiple times, MathJax **can't** provide the real solution. Polyfilling is just not fast enough. Want to make a WYSIWYG math editor using mathjax? Forget it. Want to ever send an html email with math notation, a screenshot is your best bet right now. "The book of nature is written in the language of mathematics."  Galileo Yes, Web components, Shadow Dom, Html Imports, Polymer, is also very exciting, I understand that you put a lot of effort there. But prioritizing this above supporting the language of mathematics to be written natively on one of the currently most popular communication software, is just a bloody shame! Euclid, Pythagoras, Newton, Leibniz, Fibonacci, Turing, Descartes, Riemann, Gauss, Euler and Leonardo da Vinci, would all turn in their graves, hearing about the priority you guys are given to the language of mathematics... Issue 561866 has been merged into this issue. Hopefully these concerns will be updated by the Chrome team. Please consider adding MathML!! I do not know why people use Chrome. Just use Firefox. I am sick of this useless attitude of Google people and whoever contributes to this project. I have to put a notice on my site about MathML compatibility just because of this. Those who want to visit my site they must use a MathML browser. I do not care for users of chrome. So who is the looser? Chrome team. Please add support for MathML. Being able to accurately represent formulas on the web is critical to explanation and understanding of mathematical concepts especially in distance and hightech learning environments, which are becoming more and more prevalent. Thanks. Please pardon this plus one equivalent, but this issue is becoming increasingly important to those of us in math and science education. Chrome just surpassed IE as the most widely used browser by some measures. FireFox is a deeply distant third at best. My students primary means of access to the Internet is increasingly via Chrome on Android cell phones using the college wifi. The low household incomes in the nation in which I work in means students do not usually have phones that have space for two full fledged browsers. Nor is the iPhone and Safari an affordable option. I hand code MathML in course materials, having MathML natively implemented in Chrome is a learning need of my students here. Hi, I very good chrome extension from www.fmath.info. Free to use and very performant. https://chrome.google.com/webstore/detail/fmathhtml%2Bmathmlsolut/emdjdpchbjipnjhkfljbcapgfecmnglm regards Ionel Alexandru This is height of bizarreness, a company that can build a driver less car can't implement MathML in browser. Go figure.
I can not fathom how a company that can afford to fill their headquarters with rubber ducks because they thought it would be funny can't afford to hire the coders needed to make MathML work. MathML is part of the HTML5 standard. And no, downloading a JavaScript widget isn't an appropriate solution, that causes problems when viewing offline or when there are accessibility issues. Google, do the right thing and support the standard.
Adding components affected by this feature. Google, please make an effort to fix this. Google pls enable Mathml support in Chrome. This is HTML 5 standard... pls enable Mathml support in Chrome. This is HTML 5 standard
Everyone, this is a launch tracking issue for Chromium's internal process. This is not a feature request issue. Please add a comment on Issue 6606 if you'd like to say something, or check a star on it. Checking a star on the issue would be recognized as a vote for a feature request.
If Chrome does not intend to support MathML, it should at least provide information how to handle pages with math. For instance, there is a "Math Anywhere" plugin. However, it sounds strange to me that there are about 50000 issues on SVG (Section 4.7.15 in the HTML5 standard [1]) and the one issue regarding MathML Section 4.7.14 in the same standard is closed as a feature request. [1] https://www.w3.org/TR/html5/embeddedcontent0.html hi
Showing comments 30  129
of 129
Older ›


►
Sign in to add a comment 