Chromium: "MathML is not something that we want at this time"(code.google.com)
code.google.com
Chromium: "MathML is not something that we want at this time"
https://code.google.com/p/chromium/issues/detail?id=152430#c43
107 comments
So why didn't you say that at the time this was being proposed? Now we have yet another part of the standards that people can't actually use because one browser vendor didn't like it for a vague reasons.
It undermines the process to go around cheering for HTML5 and then later decide that you don't like it after all.
It undermines the process to go around cheering for HTML5 and then later decide that you don't like it after all.
That approach makes sense for technologies outside of the scope of the HTML5 spec, but for a core element like <math> it seems rather silly to propose external implementation using custom elements (and therefore requiring Javascript availability, which shouldn't be taken for granted).
The engine obviously does support javascript, so an alternative is ensure extensions can "plug in" these custom elements and implement them in JS in a separate sandbox regardless of whether JS is enabled or disabled for the page itself.
Less code with direct OS access sounds good to me.
Less code with direct OS access sounds good to me.
But you'd still have to download and install the extension in order to use it (or, as was somewhat glibly proposed in a comment on the bug, Google would need to ship a version of MathJax with Chrome). Anyone without the extension and with JS disabled would still be out of luck.
So far as direct OS access, I'm having trouble envisioning a situation in which the layout code for MathML would be any more vulnerable than SVG (or the rest of the layout engine for that matter).
So far as direct OS access, I'm having trouble envisioning a situation in which the layout code for MathML would be any more vulnerable than SVG (or the rest of the layout engine for that matter).
Didnt XHTML stand for eXtensible HTML ? maybe XHTML was the right way at first place , just saying.
XHTML _was_ right. People were just too lazy to close there tags and did not really understood what would the consequences of not having a robust and formal way to extend the language.
HTML went the same way other popular languages (e.g.: VB, PHP, Perl), they got broad adoption because the compiler/interpreter/renderer would be too kind in working hard to fix user mistake instead of reporting them.
And then, when they tried to fix it, the same user base complain (despite being bitten many times by the language) that it should stay like it is, because it has always been like that.
When bad habits became traditions, you are really in a bad position.
HTML went the same way other popular languages (e.g.: VB, PHP, Perl), they got broad adoption because the compiler/interpreter/renderer would be too kind in working hard to fix user mistake instead of reporting them.
And then, when they tried to fix it, the same user base complain (despite being bitten many times by the language) that it should stay like it is, because it has always been like that.
When bad habits became traditions, you are really in a bad position.
No: http://web.archive.org/web/20081211052740/http://diveintomar...
"The client is the wrong place to enforce data integrity. It’s just the wrong place. I hear otherwise intelligent people claim that if everyone did it, it would be okay. No, if everyone did it, it would be even worse. If you want to do it, of course I can’t stop you. But think about who it will hurt."
"The client is the wrong place to enforce data integrity. It’s just the wrong place. I hear otherwise intelligent people claim that if everyone did it, it would be okay. No, if everyone did it, it would be even worse. If you want to do it, of course I can’t stop you. But think about who it will hurt."
Hard to see how it would have been worse if all browsers had implemented stop-on-error, because then the developer/tester's browser would not have rendered the erronous page. That would mean that the developer/tester would have had to not try the page even once before shipping, if a bad page were to make it to production.
The page only became bad when the blog received a trackback from a different blog with a different character set. At that point the blog software erroneously changed the page's content and made it invalid. It was a software bug, plain and simple. The page was fully valid when the blog author published it.
For the developer/tester of Typepad (the blog software) to catch the bug, they would have had to trigger this bug in development/testing before it made it into the wild. While we always hope developers will catch as many bugs as possible, some will always slip through. Strict validation on the client means that even the slightest bug can make the website 100% down/unavailable, even though the browser would be perfectly capable of displaying something that 99% works.
Modern web sites are huge amalgamations of dynamically-generated content using umpteen templating technologies and aggregations of data that come from sources that the page's authors do not necessarily control. Guaranteeing that their output will always be valid XHTML is not trivial.
For the developer/tester of Typepad (the blog software) to catch the bug, they would have had to trigger this bug in development/testing before it made it into the wild. While we always hope developers will catch as many bugs as possible, some will always slip through. Strict validation on the client means that even the slightest bug can make the website 100% down/unavailable, even though the browser would be perfectly capable of displaying something that 99% works.
Modern web sites are huge amalgamations of dynamically-generated content using umpteen templating technologies and aggregations of data that come from sources that the page's authors do not necessarily control. Guaranteeing that their output will always be valid XHTML is not trivial.
Bringing attention to errors and attempting to recover from errors aren't mutually exclusive. I would much prefer that poorly formed pages cause the address bar to change in some visually distinctive way, similar to how modern browsers make part of the address bar green for pages retrieved over HTTPS. Another option would be to display an error page with a button that says something to the effect of "try and guess what the lazy developer wanted".
An inability to guarantee valid output hints that inputs aren't being properly analyzed and sanitized, with terrible security consequences. Both developers and users of pages should be made aware when these errors occur.
If the error messages are too intrusive, adoption of browsers displaying them would of course suffer greatly.
An inability to guarantee valid output hints that inputs aren't being properly analyzed and sanitized, with terrible security consequences. Both developers and users of pages should be made aware when these errors occur.
If the error messages are too intrusive, adoption of browsers displaying them would of course suffer greatly.
I disagree. The issue described is an input sanitisation issue. The same thing would have happen to a SQL query and everyone would have put shame on you.
It IS a bug that the blog engine developers should have catch, in the same way they should have protect the trackback from XSS injection.
Guaranteeing your output will always be valid might not be trivial, but it is way less harder that some people pretend it to be.
It IS a bug that the blog engine developers should have catch, in the same way they should have protect the trackback from XSS injection.
Guaranteeing your output will always be valid might not be trivial, but it is way less harder that some people pretend it to be.
Bugs will slip through. They just will, it's a fact of life.
The question is, when they do, will you let the browser gracefully recover, or will you demand that the browser show an error page, even though it could do something reasonable?
The security analogy would be to let all your code run as root, because the main security mechanisms should prevent users from executing arbitrary code. But this is fragile, because any security bug would compromise the security of the system completely.
What we do instead is have defense in depth: even if the first layer of security is compromised, there are other layers of security that can (hopefully) contain the damage. Permissive client rendering likewise limits the damage that one bug can do.
The question is, when they do, will you let the browser gracefully recover, or will you demand that the browser show an error page, even though it could do something reasonable?
The security analogy would be to let all your code run as root, because the main security mechanisms should prevent users from executing arbitrary code. But this is fragile, because any security bug would compromise the security of the system completely.
What we do instead is have defense in depth: even if the first layer of security is compromised, there are other layers of security that can (hopefully) contain the damage. Permissive client rendering likewise limits the damage that one bug can do.
Having seen so many failure getting worse because people did not paid attention to it in the first place, I would go for the error page.
That said, even if we choose a defense in depth, it still is not a valid reason to throw away XHTML as it was done.
The same way you will not remove your firewall because it does not block dormant viruses, but add an antivirus, the browsers could have still continue putting effort in rendering the correct, and powerful, XHTML, while setting down some decent fallbacks to recover. Being we a be red warning to raise awareness that something need to be fixed.
That said, even if we choose a defense in depth, it still is not a valid reason to throw away XHTML as it was done.
The same way you will not remove your firewall because it does not block dormant viruses, but add an antivirus, the browsers could have still continue putting effort in rendering the correct, and powerful, XHTML, while setting down some decent fallbacks to recover. Being we a be red warning to raise awareness that something need to be fixed.
maybe XHTML was the right way at first place , just saying.
It very probably was. The path we're going down with HTML5 and "modern" browser technologies is taking a muddled clusterfuck of a mess, and making it even more muddled and even more of a clusterfuck. It'll work, but only through heroic effort and sacrifice.
I feel like we're painting ourselves into a corner with the web these days, and actually reducing choice and flexibility on the web. One thing that is clear, is that we've lost sight of the distinction between a document and an application, and have managed to turn a pretty good hypertext platform into a Dr. Frankentein's Monster that combines hypertext browsing and a poor man's X-server in eldritch and grotesque ways.
It very probably was. The path we're going down with HTML5 and "modern" browser technologies is taking a muddled clusterfuck of a mess, and making it even more muddled and even more of a clusterfuck. It'll work, but only through heroic effort and sacrifice.
I feel like we're painting ourselves into a corner with the web these days, and actually reducing choice and flexibility on the web. One thing that is clear, is that we've lost sight of the distinction between a document and an application, and have managed to turn a pretty good hypertext platform into a Dr. Frankentein's Monster that combines hypertext browsing and a poor man's X-server in eldritch and grotesque ways.
Here's a Mozilla mailing list thread discussing dropping MathML support. The linked post explains why MathML is desirable (e.g., accessibility, performance, accuracy of rendering, standards compliance, necessary for ebooks).
https://groups.google.com/d/msg/mozilla.dev.platform/96dZw1j...
https://groups.google.com/d/msg/mozilla.dev.platform/96dZw1j...
The Chromium guys really don't like to add new features based on user requests.
Here[1] they refuse to add support for SIL Graphite[2], which is essential for making text in certain languages render correctly. (Of course, Firefox already supports it.)
Comment #9 was the same guy ranting against libgraphite2's code quality, but it's been deleted now.
Thankfully, they've since changed their mind on that one. We might still see Graphite support in Chrome.
[1] http://code.google.com/p/chromium/issues/detail?id=140007#c7
[2] http://scripts.sil.org/cms/scripts/page.php?site_id=projects....
Here[1] they refuse to add support for SIL Graphite[2], which is essential for making text in certain languages render correctly. (Of course, Firefox already supports it.)
Comment #9 was the same guy ranting against libgraphite2's code quality, but it's been deleted now.
Thankfully, they've since changed their mind on that one. We might still see Graphite support in Chrome.
[1] http://code.google.com/p/chromium/issues/detail?id=140007#c7
[2] http://scripts.sil.org/cms/scripts/page.php?site_id=projects....
"Comment #9 was the same guy ranting against libgraphite2's code quality, but it's been deleted now."
Is there anything to say he was wrong?
"Thankfully, they've since changed their mind on that one. We might still see Graphite support in Chrome."
So what your saying is that after the serious code quality issues he apparently ranted about disappeared, they reconsidered (that's what the comment stream seems to say ...)?
Is there anything to say he was wrong?
"Thankfully, they've since changed their mind on that one. We might still see Graphite support in Chrome."
So what your saying is that after the serious code quality issues he apparently ranted about disappeared, they reconsidered (that's what the comment stream seems to say ...)?
This decision is potentially very big. How can Chrome, a browser that has so actively pushed HTML5 forward, reject a component of the spec? I mean IE supports WebGL for crying out loud, I wasn't sure they ever would, but even they're playing ball.
We'll see what happens here, its a pretty vague comment right now. What does "at this time" really mean? Is it just delayed so other things can be focused on? I could understand that. Things like the new input controls should be a bigger priority, they are more important for 99% of all users.
Very interesting, it makes it hard for Chrome to criticize any other implementation.
We'll see what happens here, its a pretty vague comment right now. What does "at this time" really mean? Is it just delayed so other things can be focused on? I could understand that. Things like the new input controls should be a bigger priority, they are more important for 99% of all users.
Very interesting, it makes it hard for Chrome to criticize any other implementation.
I don't understand - doesn't Google want the web to be a first-class platform for scientific research? Chrome is supposed to be the standards-compliant browser! Not to mention, if scientists have an easy way of creating markup versions of their LaTeX files you'll see a huge influx of scientific work on the web!
I think if you look at the MathML standard or some example markup you'll understand. MathML is prohibitively verbose. It comes in two flavors, display and structural, and neither one is amenable to busting out equations. Even when MathML is universally supported by browsers it will still be treated as fundamentally an interchange format seldom seen by human eyes, mostly generated by systems like MathJax from human-friendly TeX.
As long as you're converting TeX math to something else, MathML is preferable only because it may look nicer rendered than an image raster from TeX.
As long as you're converting TeX math to something else, MathML is preferable only because it may look nicer rendered than an image raster from TeX.
MathML is a valid compile target for TeX equations, it doesn't matter how easy it is to write by hand nor does it matter how verbose it is. It is intended to be an interchange format seldom seen by human eyes or written by human authors.
When the OP says "if scientists have an easy way of creating markup versions of their LaTeX files" it sounds like they'll be writing it by hand, don't you think? Alternatively, a toolchain involving compilation to HTML+MathML doesn't sound to me like a problem for browser vendors.
svg with a alt tag of the TeX source...
And we write markdown not HTML. So what? Images are a terrible non solution.
HTML is not user-hostile and MathML is. I'm saying this has something to do with lack of uptake for the latter.
Why not target SVG?
I disagree and think that this is best done in userland. Adding native support for features that aren't critical can retard future development significantly.
I think being able to easily render mathematical expressions is critical, almost as critical as rendering linguistic expressions, if the web wants to be taken seriously as a place to publish scientific work and not just upload science as a different mime-type attachment. Many scientists are highly technical with regard to their field, but when it comes to web development, they have no idea how to write HTML, let alone how to include a javascript file in their HTML documents.
"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."
This, coupled with the fact that WebKit MathML wasn't up to snuff, is a pretty good rationale IMO.
Standards-compliance is a means to an end (interoperability), doesn't mean browsers should implement every niche spec that someone comes up with. I want my VRML first, at least ;)
This, coupled with the fact that WebKit MathML wasn't up to snuff, is a pretty good rationale IMO.
Standards-compliance is a means to an end (interoperability), doesn't mean browsers should implement every niche spec that someone comes up with. I want my VRML first, at least ;)
So maybe they should support LaTeX directly?
(not speaking on behalf of anyone than me)
That would be a Chrome-specific non-standard feature. If JavaScript implementation of TeX is too slow, a Chrome-specific solution would be NaCl/PNaCl.
But I really recommend to evaluate how to generate high-performance javascript code (like with Emscripten) and have it working fast enough.
That would be a Chrome-specific non-standard feature. If JavaScript implementation of TeX is too slow, a Chrome-specific solution would be NaCl/PNaCl.
But I really recommend to evaluate how to generate high-performance javascript code (like with Emscripten) and have it working fast enough.
Thanks. My comment might not seem on the level but I honestly wonder whether LaTeX support would have more broad impact than a subset like MathML.
That would be ideal but TeX source is supposedly very big and complicated.
MathML is a joke compared to LaTeX. HTML + canvas, SVG, or PNG is preferable.
MathML is a joke compared to LaTeX. HTML + canvas, SVG, or PNG is preferable.
Over at the chrome dev team: "Oh shit, it's in the spec?"
HTML5 Section 4.8.15 Embedded Content - MathML http://www.w3.org/html/wg/drafts/html/CR/embedded-content-0....
Obviously. Chrome is only about pushing out features which Google needs to deliver their platforms and products.
MathMl, despite being in the spec does nothing to this end.
MathMl, despite being in the spec does nothing to this end.
Or, you know, you could not always assume the worst.
Did you think the same when mozilla seriously considered dropping it?
the difference is the discussion that happened, where also mozilla employees weighted in to support mathml. there is afaik no open discussion in chrom(ium|e).
First there is a discussion on the bug report.
How is that not open?
If you want a mailing list discussion, did you start a discussion on chromium-dev, or is your complaint that nobody else did?
From what I see, the discussion existed on a bug report because that is how it was reported by a user as a feature request. Support was never complete, the person maintaining it stopped doing so, etc.
If you want a mailing list discussion, did you start a discussion on chromium-dev, or is your complaint that nobody else did?
From what I see, the discussion existed on a bug report because that is how it was reported by a user as a feature request. Support was never complete, the person maintaining it stopped doing so, etc.
How do you explain Google Scholar or the Research feature in Google Docs?
Created in the same era as Google Code Search and likely to meet the same fate.
They can probably file it under hiring costs. It's a very effective branding measure targeted towards all the academics they need.
While researchers have to search for publications all the time, I don't see many use cases for a code search engine.
While researchers have to search for publications all the time, I don't see many use cases for a code search engine.
You've not spent much time trying to use insufficiently documented APIs then. I used Google Code Search all the time -- now I search on GitHub.
Since Google is a software company as well as a research laboratory (though I would say it is more prominently the former), I would be surprised that they would kill Code Search but keep Scholar alive as a hiring cost.
Since Google is a software company as well as a research laboratory (though I would say it is more prominently the former), I would be surprised that they would kill Code Search but keep Scholar alive as a hiring cost.
I think the "research" feature is way more recent. OTOH, it appears to be targeted at high school students writing an history essay, more than to people discussing phd level algebra.
Even MathJax would be much better than what many large sites, including Wikipedia, still use - static images. It's very annoying not to be able to search for things inside the math, and the images are low resolution and ugly on a Retina Display.
(However, I guess Wikipedia has a MathJax option; I wonder why it's not enabled by default.)
(However, I guess Wikipedia has a MathJax option; I wonder why it's not enabled by default.)
Maybe they get a lot of those mythical users who don't have Javascript enabled.
It's possible to support both options. Alternately, in theory I don't see why the math couldn't be rendered on the server, although I don't think MathJax can currently do this.
Similar to this (but with a different syntax)? http://www.quicklatex.com/
This appears to render to an image, which has the problems I mentioned. MathJax renders to HTML.
Please everyone, stop acting so holy about "the spec". The HTML spec isn't sacred. It's very reasonable to discuss it, even after a feature has been approved.
How else will we improve the existing features? If we don't change existing things, the browser will stay the stinking ball of backwards compatible code it is today.
How else will we improve the existing features? If we don't change existing things, the browser will stay the stinking ball of backwards compatible code it is today.
>Please everyone, stop acting so holy about "the spec". The HTML spec isn't sacred.
This argument is never accepted when it comes from Microsoft. When they refuse to implement a standard it's an 'attack on the web' and MS trying to 'kill' the web for their own commercial interests. When Google rejects a standard and their public reasoning is that they can't be bothered to finish the implementation (it was already in Webkit after all) then we should just accept it. But why? Because Google is 'good' and Microsoft is 'bad'?
The reality is that MathML isn't in Googles commercial interest so it won't get done. That is the real story behind all the happy sing-alongs about the open web: it is ruled by a couple of teams in large powerful corporations who have the power to kill any part of the standard that conflicts with their commercial interests, or even just fails to promote their commercial interests.
This argument is never accepted when it comes from Microsoft. When they refuse to implement a standard it's an 'attack on the web' and MS trying to 'kill' the web for their own commercial interests. When Google rejects a standard and their public reasoning is that they can't be bothered to finish the implementation (it was already in Webkit after all) then we should just accept it. But why? Because Google is 'good' and Microsoft is 'bad'?
The reality is that MathML isn't in Googles commercial interest so it won't get done. That is the real story behind all the happy sing-alongs about the open web: it is ruled by a couple of teams in large powerful corporations who have the power to kill any part of the standard that conflicts with their commercial interests, or even just fails to promote their commercial interests.
Stop making everything so black and white. No corporation is 'good', nor 'evil'.
Yes, the spec is run by corporations. No, that's not evil. Yes, they'll probably promote their own interests. No, that's not the end of the world.
Yes, the spec is run by corporations. No, that's not evil. Yes, they'll probably promote their own interests. No, that's not the end of the world.
I wasn't saying I think they are good or evil. I was saying that kind of black and white thinking seems to be what leads the web community to attack MS for ignoring standards but defend Google for doing the same.
>Yes, the spec is run by corporations. No, that's not evil. Yes, they'll probably promote their own interests. No, that's not the end of the world.
It's fine as long as we have native open platforms that we can use instead. However Google and Mozilla want us all to be running web based OSs. In that world yes it would be a huge deal for one player to block a standard.
>Yes, the spec is run by corporations. No, that's not evil. Yes, they'll probably promote their own interests. No, that's not the end of the world.
It's fine as long as we have native open platforms that we can use instead. However Google and Mozilla want us all to be running web based OSs. In that world yes it would be a huge deal for one player to block a standard.
[deleted]
Not a web guy, but my understanding of most attacks against IE is where it implemented the spec incorrectly, particularly with CSS. However, if they're being attacked because they don't implement something that's a different case.
Microsoft was attacked with these arguments when they decided not to implement WebGL in Internet Explorer 10.
Yeah, I realized that a couple minutes ago. Not a full defense of that attack, but that decision by MS may have reminded people of the Direct3d vs OpenGL fight that happened in the 90s.
And what about not implementing Speedy in IE 10? Not implementing Touch Events in IE 11 (Internet Explorer uses Pointer Events instead)? Here I remembered some sh*tstorms, too.
Before all the chrome and Google bashing starts...
The point is why do we need something specific for math. Would people be OK with a musicml? Or say chemicalml? And that's a good question. Why is math so special? Let's try to solve the problem more generically instead of adding specialized domains in the browser.
The point is why do we need something specific for math. Would people be OK with a musicml? Or say chemicalml? And that's a good question. Why is math so special? Let's try to solve the problem more generically instead of adding specialized domains in the browser.
There's a long thread on mozilla.dev.platform[1] that lays out the arguments for MathML quite well.
I'd also add that there is a W3C Math WG, and has been for over a decade. I would have thought the question of whether or not MathML is desirable would have been answered at some point in that time frame before it became a W3C Recommendation.
[1] https://groups.google.com/forum/#!msg/mozilla.dev.platform/9...
I'd also add that there is a W3C Math WG, and has been for over a decade. I would have thought the question of whether or not MathML is desirable would have been answered at some point in that time frame before it became a W3C Recommendation.
[1] https://groups.google.com/forum/#!msg/mozilla.dev.platform/9...
That thread starts with a pretty well reasoned argument for dropping MathML ("Summary: MathML is a vestigial remnant of the XML-everything era, and we should drop it."), and a later message provides more background for WebKit/Blink MathML problems: "The Blink implementation was never good enough to render MathML pages well in the real world, whether there were any or not. It also had some pretty major brokenness in the way it was integrated into Blink, which made it difficult to enable safely. "
and there are very many arguments pro MathML in it as well, which makes the reasoning seem not so well founded.
to quote one rebuttal of every point the thread op made:
1.1. you make a point against adding unnecessary typography. Mathematics is text, but adding new requirements. It's comparable to the introduction of RTL or tables much more than musical notation. It's also something that all school children will encounter for 9-12 years. IMHO, this makes it necessary to implement mathematical typesetting functionality.
1.2 you claimed MathML is inferior to TeX. I've tried to point out that that's not the case as most scientific and educational publishers use it extensively.
1.2.1 you claimed TeX is the universal standard. I've tried to point out only research mathematicians use it as a standard. Almost most mathematics happens outside that group.
1.2.2 You pointed out that MathML isn't friendly to manual input. That's true but HTML isn't very friendly either, nor is SVG.
1.2.3 You argued TeX is superior for accessibility. I've pointed out that that's not the case given the current technology landscape.
2 You wrote now is the time to drop MathML. I've tried to point out that now -- as web and ebook standard -- is the time to support it, especially when your implementation is almost complete and you're looking to carve a niche out of the mobile and mobile OS market, ebooks etc.
2.1 you claim MathML never saw traction outside of Firefox. I tried to point out that MathML has huge traction in publishing and the educational sector, even if it wasn't visible on the web until MathJax came along. Google wants MathML support (they just don't trust the current code) while Apple has happily advertised with the MathML they got for free. Microsoft indeed remains a mystery.
2.2 you claim MathJax does a great job -- ok, I'm not going to argue ;) -- while browsers don't. But we've used native output on Firefox before MathJax 2.0 and plan to do it again soon -- it is well implemented and can provide the same quality of typesetting.
3. Well, I'm not sure what to say to those. If math is a basic typographical need, then the syntax doesn't matter -- we need to see it implemented and its bottom up layout process clashes with CSS's top down process. No change in syntax will resolve that.
to quote one rebuttal of every point the thread op made:
1.1. you make a point against adding unnecessary typography. Mathematics is text, but adding new requirements. It's comparable to the introduction of RTL or tables much more than musical notation. It's also something that all school children will encounter for 9-12 years. IMHO, this makes it necessary to implement mathematical typesetting functionality.
1.2 you claimed MathML is inferior to TeX. I've tried to point out that that's not the case as most scientific and educational publishers use it extensively.
1.2.1 you claimed TeX is the universal standard. I've tried to point out only research mathematicians use it as a standard. Almost most mathematics happens outside that group.
1.2.2 You pointed out that MathML isn't friendly to manual input. That's true but HTML isn't very friendly either, nor is SVG.
1.2.3 You argued TeX is superior for accessibility. I've pointed out that that's not the case given the current technology landscape.
2 You wrote now is the time to drop MathML. I've tried to point out that now -- as web and ebook standard -- is the time to support it, especially when your implementation is almost complete and you're looking to carve a niche out of the mobile and mobile OS market, ebooks etc.
2.1 you claim MathML never saw traction outside of Firefox. I tried to point out that MathML has huge traction in publishing and the educational sector, even if it wasn't visible on the web until MathJax came along. Google wants MathML support (they just don't trust the current code) while Apple has happily advertised with the MathML they got for free. Microsoft indeed remains a mystery.
2.2 you claim MathJax does a great job -- ok, I'm not going to argue ;) -- while browsers don't. But we've used native output on Firefox before MathJax 2.0 and plan to do it again soon -- it is well implemented and can provide the same quality of typesetting.
3. Well, I'm not sure what to say to those. If math is a basic typographical need, then the syntax doesn't matter -- we need to see it implemented and its bottom up layout process clashes with CSS's top down process. No change in syntax will resolve that.
> The point is why do we need something specific for math.
You seem not to have been around when we had to do it over plain text. It sucked. MathML is a huge gain for sharing thoughts over scientific matters. Of course, they aren't as important to today's "open web" compared to, say, ads and making text rumble with JS, but they shouldn't be relegated to an entirely unimportant position, especially considered they're part of the famous HTML5 standard that should supposedly deliver us from the dreaded fractures between platforms.
You seem not to have been around when we had to do it over plain text. It sucked. MathML is a huge gain for sharing thoughts over scientific matters. Of course, they aren't as important to today's "open web" compared to, say, ads and making text rumble with JS, but they shouldn't be relegated to an entirely unimportant position, especially considered they're part of the famous HTML5 standard that should supposedly deliver us from the dreaded fractures between platforms.
"Why is math so special?".
Try counting up the fields that use mathematical notation versus musical and chemical notation.
Is "counting the fields" how we should consider all Chrome feature requests? A browser's user is not a field.
I love the semantics heroes here on HN.
That would be a pretty good argument if MathML weren't in the HTML5 spec
Why is math so special?
Asked at Hackernews?
Really?
Asked at Hackernews?
Really?
Is asking that off limits? If it's so obvious and easy to understand, explain it. Also, Chrome caters to a very wide audience so dev time has to consider a much broader audience than hackers.
The problem is that the Chrome team shouldn't be selectively implementing parts of the html5 standard [1]. It shouldn't matter how many users desire the functionality after it's accepted by the w3c.
Of course, Chrome could implement whatever it likes if it drops any claim to be standards compliant, but until that happens...
[1] http://www.w3.org/Math/draft-spec/mathml.html
Of course, Chrome could implement whatever it likes if it drops any claim to be standards compliant, but until that happens...
[1] http://www.w3.org/Math/draft-spec/mathml.html
[deleted](2)
What ?
Of course they should.
It's all about choice. There are a shitload of standards and a limited amount of man-hour.
So why not just say we would like to do this but don't have time ?
The impression I got was that they would never implement it.
The impression I got was that they would never implement it.
Just to explain the joke: Math is special to us nerds.
So the Chrome team should implement this because...
Do MusicML or ChemicalML exist yet? I'd be interested even in the specifications if you've got some links. A quick Google didn't net much.
MusicXML does: http://en.wikipedia.org/wiki/MusicXML
The closest thing to an open-source in-browser JS renderer would be something based on https://github.com/0xfe/vexflow, but a reliable converter for MusicXML hasn't been written yet.
Yes to ChemicalML:
http://en.wikipedia.org/wiki/Chemical_Markup_Language
http://en.wikipedia.org/wiki/Chemical_Markup_Language
The point is why do we need something specific for math.
Considering that the roots of the WWW are in a scientific research organization (CERN)[1], and considering how much scientific users use maths, then yeah, I'd say it makes sense that maths should be a native part of the WWW platform.
[1]: http://www.w3.org/History.html
Considering that the roots of the WWW are in a scientific research organization (CERN)[1], and considering how much scientific users use maths, then yeah, I'd say it makes sense that maths should be a native part of the WWW platform.
[1]: http://www.w3.org/History.html
[deleted]
[deleted]
I don't particularly care that it's in the spec, personally. MathML is horrid. This page covers it well: http://aiju.de/rant/XML/MathML
If we were going to reject technologies because they were horrid there wouldn't be much of the web left. HTML is horrid. CSS is horrid. Javascript is horrid.
MathML is not meant to written by hand, but to be an easy to implement and easy to parse compiler target.
This is actually somewhat funny.
It combines the best parts of binary and text formats!
It's slow to parse just like text and impossible to change by hand just like binary!
But seriously. MathML is a huge mistake. They could've designed an actually writable format, but they didn't. It's one of the best examples of XML architects going over the top.
It combines the best parts of binary and text formats!
It's slow to parse just like text and impossible to change by hand just like binary!
But seriously. MathML is a huge mistake. They could've designed an actually writable format, but they didn't. It's one of the best examples of XML architects going over the top.
There's a part of me that feels like the web has gone too far in the direction of overly concentrating power into the hands of the browser vendors.
I would love to see somebody fork Firefox or Chromium and create a browser that:
a. does implement all the relevant web standards ( like MathML, SVG, etc., etc.)
b. is more responsive to the community than current Firefox or Chrome
c. can serve as a testbed for experimenting with new web based technologies.
Sadly, a lot of that is what Mozilla purported to be waaaaayyyy back in the early days (I'm talking 1998 or so), but at some point they (Mozilla) decided that competing with IE for market-share was the #1 priority.
Of course part of the problem is that browsers are big, complicated, difficult projects, and it takes a lot of resources to maintain and build one. So I'm not too optimistic about seeing this mythical "more community driven browser" emerge anytime soon. sigh
All of that said, I'd love to see some experimentation around actually making a sharp distinction between documents and applications and some mechanisms for "handing off" application "stuff" to something other than the browser where the goal is to remote out the UI to an app. JNLP was a good start on that, but Sun's failure to deliver something like the Consumer JRE about 7 years sooner, and then the rash of JRE security bugs, more or less killed that as a viable possibility. But something like JNLP, not tied to Java, and with fast startup times and without the security bugs, could be very interesting.
I just wish I had time to experiment with this myself, but sadly I'm too heads down grinding on other things. :-(
I would love to see somebody fork Firefox or Chromium and create a browser that:
a. does implement all the relevant web standards ( like MathML, SVG, etc., etc.)
b. is more responsive to the community than current Firefox or Chrome
c. can serve as a testbed for experimenting with new web based technologies.
Sadly, a lot of that is what Mozilla purported to be waaaaayyyy back in the early days (I'm talking 1998 or so), but at some point they (Mozilla) decided that competing with IE for market-share was the #1 priority.
Of course part of the problem is that browsers are big, complicated, difficult projects, and it takes a lot of resources to maintain and build one. So I'm not too optimistic about seeing this mythical "more community driven browser" emerge anytime soon. sigh
All of that said, I'd love to see some experimentation around actually making a sharp distinction between documents and applications and some mechanisms for "handing off" application "stuff" to something other than the browser where the goal is to remote out the UI to an app. JNLP was a good start on that, but Sun's failure to deliver something like the Consumer JRE about 7 years sooner, and then the rash of JRE security bugs, more or less killed that as a viable possibility. But something like JNLP, not tied to Java, and with fast startup times and without the security bugs, could be very interesting.
I just wish I had time to experiment with this myself, but sadly I'm too heads down grinding on other things. :-(
Hopefully Gecko and WebKit will forge ahead with this. There are members of the community willing to work on MathML:
http://www.maths-informatique-jeux.com/blog/frederic/?post/2...
http://www.maths-informatique-jeux.com/blog/frederic/?post/2...
"... several engineering weeks had already been spent trying to resolve the security issues before we were forced to disable the code."
It's not clear what other issues are causing them to not adopt MathML, but this was at least a severe one, and nobody in any of these comments seems to have acknowledged it. The sentence quoted in the title may have been a bit of a mis-statement, since every other bit of discussion is about maintenance and security issues, not a philosophical rejection.
(I'm not sure I understand this correctly, but the other comments here have not helped at all.)
It's not clear what other issues are causing them to not adopt MathML, but this was at least a severe one, and nobody in any of these comments seems to have acknowledged it. The sentence quoted in the title may have been a bit of a mis-statement, since every other bit of discussion is about maintenance and security issues, not a philosophical rejection.
(I'm not sure I understand this correctly, but the other comments here have not helped at all.)
Sure, great decision! If nerds want math, they can type it with -xxx-border-radious hacks.
Seriously, the only cross-browser way left to have nice looking equations without MathJAX is to make SVGs with dvisvgm, of course for the cost of interoperability.
Seriously, the only cross-browser way left to have nice looking equations without MathJAX is to make SVGs with dvisvgm, of course for the cost of interoperability.
I've been using bing as an experiment for the last three weeks or so. Google is far better for academic searches, and better support for math rendering would help extend the lead in that category. Isn't that reason enough?
Google exists to advertise. Academics are woefully underpaid. Who wants to advertise to a bunch of broke intellectuals that are just going to ignore your ads anyways?
Doctors are perfectly good candidates for ad targeting, and some are paid quite well (even at academic research hospitals). Those institutions also have quantitative science departments.
Does MathJax play well with screen readers and other accessibility solutions?
Does MathML? (Excluding imaginary screen readers – imaginary screen readers can support anything.)
imaginary screen readers?
Yes, there are solutions for MathML for accessibility.
Yes, there are solutions for MathML for accessibility.
One of our goals is to make it possible to layer technologies as complex as MathML on top of Blink without requiring Blink to ship everything and the kitchen sink. See new technologies like Custom Elements (http://www.w3.org/TR/custom-elements/), which are part of this story.