
Chromium: "MathML is not something that we want at this time" - dak1
https://code.google.com/p/chromium/issues/detail?id=152430#c43
======
fishd
Please read the rest of what Ojan wrote: "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."

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/](http://www.w3.org/TR/custom-
elements/)), which are part of this story.

~~~
camus2
Didnt XHTML stand for eXtensible HTML ? maybe XHTML was the right way at first
place , just saying.

~~~
gizmogwai
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.

~~~
haberman
No:
[http://web.archive.org/web/20081211052740/http://diveintomar...](http://web.archive.org/web/20081211052740/http://diveintomark.org/archives/2004/01/14/thought_experiment)

"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."

~~~
sixbrx
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.

~~~
haberman
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.

~~~
gizmogwai
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.

~~~
haberman
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.

~~~
gizmogwai
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.

------
jonchang
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/96dZw1jXTvM/rIzKSrRgk18J)

------
chattoraj
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](http://code.google.com/p/chromium/issues/detail?id=140007#c7)

[2]
[http://scripts.sil.org/cms/scripts/page.php?site_id=projects...](http://scripts.sil.org/cms/scripts/page.php?site_id=projects..).

~~~
DannyBee
"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 ...)?

------
tyleregeto
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.

------
Aqueous
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!

~~~
fusiongyro
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.

~~~
ovangle
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.

~~~
fusiongyro
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.

------
eof
Over at the chrome dev team: "Oh shit, it's in the spec?"

~~~
lcnmrn
TeX should be part of the HTML spec too.

Why not <tex>E = mc^2</tex>?

~~~
Skalman
Because that's not possible to style with CSS.

------
josteink
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.

~~~
DannyBee
Or, you know, you could not always assume the worst. Did you think the same
when mozilla seriously considered dropping it?

~~~
ibotty
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).

~~~
DannyBee
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.

------
comex
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.)

~~~
fusiongyro
Maybe they get a lot of those mythical users who don't have Javascript
enabled.

~~~
comex
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.

~~~
jaredsohn
Similar to this (but with a different syntax)?
[http://www.quicklatex.com/](http://www.quicklatex.com/)

~~~
comex
This appears to render to an image, which has the problems I mentioned.
MathJax renders to HTML.

------
AlexanderDhoore
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.

~~~
anon1385
>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.

~~~
AlexanderDhoore
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.

~~~
anon1385
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.

------
general_failure
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.

~~~
saraid216
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.

~~~
haberman
MusicXML does:
[http://en.wikipedia.org/wiki/MusicXML](http://en.wikipedia.org/wiki/MusicXML)

~~~
btown
The closest thing to an open-source in-browser JS renderer would be something
based on [https://github.com/0xfe/vexflow](https://github.com/0xfe/vexflow),
but a reliable converter for MusicXML hasn't been written yet.

------
Sir_Cmpwn
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](http://aiju.de/rant/XML/MathML)

~~~
anon1385
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.

~~~
Sir_Cmpwn
The difference here is that there are better alternatives to consider instead.

~~~
ibotty
which? i prefer _writing_ tex as (nearly) everyone, but read the mozilla
thread for arguments, why there is nothing else that might work.

------
mindcrime
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. :-(

------
eddieh
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/2013/10/12/Funding-MathML-Developments-in-Gecko-
and-WebKit)

------
JeremyBanks
_"... 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.)

------
mbq
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.

------
rch
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?

~~~
ameoba
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?

~~~
rch
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.

------
protomyth
Does MathJax play well with screen readers and other accessibility solutions?

~~~
ianbicking
Does MathML? (Excluding imaginary screen readers – imaginary screen readers
can support anything.)

~~~
protomyth
imaginary screen readers?

Yes, there are solutions for MathML for accessibility.

