The author here is saying we want a spec and support for properly displaying math content in the browser, so let's make a sane spec that works with the way the web works, not as if it's in an embedded foreign object viewer.
SVG is actually a great parallel In many instances it is easy to write by hand, until you go to any level of moderate complexity and hit the brick wall of SVG's usability. And that's when you wish it had a sane design, because there are a few aspects that are quite close.
I can't but see these as secondary to why MathML isn't supported yet. The current state works already well enough in Firefox, but no one would use it, since why support a single browser? And we've had it working nicely in Chrome before the devs pulled the plug because of lack of manpower. You could try to overrule the cruft from say the upcoming HTML5.1 spec, and find a good alignment with CSS. If it proves annoying or impossible, you could take the process further towards a MathML 4 that offers a CSS-compatible subset, etc. And the W3C Math group could approve of an experimental note much quicker, so that we don't sit around for years waiting for the standardization process.
The web mathematics community is a small one, and most of us have strong opinions on MathML. The way this debate is heading will tear the community in various tinier subfractions and likely continue the "math-on-the web winter" for another decade.
In my eyes, nothing has changed really - we've had browsers silently complicit in ignoring MathML, and a community tiny enough to not be able to move them in any direction. The two important bits for a math-on-the-web developer to have sanity are 1) expose the mathematics content of a page as data (the way we do tables) and 2) do so in a standard cross-browser way. Anything else leads to insane hacks, and tools such as math search engines, clipboards etc. can not be implemented directly.
Sadly that's not true for SVG. SVG has many parts that are only there to make writing/editing SVGs by hand easier. Circle, rectangle elements, the commas in the path strings (which follow relatively insane rules. Almost all implementations already had bugs in the correct parsing behaviour regarding commas/whitespace)
To me, it's not that I don't think there is a use case for MathML, it's that it's too content-specific to make sense at the browser level.
The only way it makes sense in my head is if I think of math as a language that browsers should support on the basis of internationalization. That makes some sense to me, but if that's the idea then OP is right they should use standard notation (as we do for every other language) and not XML, and it shouldn't be styleable by CSS at all.
If you don't, please don't say no one does. Having a math DOM allows for actual interactivity with mathematics, from highlighting, copying subtrees, embedding links, having on the fly computations/simplifications, etc.
Not to mention add-on services like math indexing and search.
Yes, we need to manipulate and machine-read math expressions, if we want to finally take online math workflows to the 21st century.
BTW, if we want a <math> tag that no one will write by hand and only machine will try to understand, then think about why not HTML being designed as some open binary format in the first place?
Images are not mathematics, they have nothing to do with mathematics. If you take a look at SVG, you may be shocked to find you can do just as much decomposition of principle components as you can do with any DOM, just the way MathML allows you to.
Please substantiate the "works pretty well" claim about your search engine with some data. Your sense of inconvenience comes far from an objective argument.
How many people write HTML by hand? Generating it from a wide range of tools, richtext editors, markdown inputs, etc etc is much more common. Your analogies are just inaccurate.
As for my "works pretty well", please refer to my answer in another thread below. To be concise, I use subjective words on search engine effectiveness because NTCIR makes it difficult to compare my TeX search engine with "MathML search engine". But I have already shown better efficiency of my engine compared to Tangent, and an important factor is Tangent have to use LaTeXML to parse every TeX back to MathML. Without considering NTCIR, I am willing to make a comparison (probably after done my new version search engine) with some open-source established math engine (e.g. Tangent) on effectiveness and efficiency based on some corpus with both MathML (used by Tangent) and TeX (used by my engine) annotation.
MathML as a spec is akin to SVG, it's meant for the browser/machine first, and not for direct human consumption. You don't read/write SVG by hand, and neither you should MathML.
MathML by itself is only half an answer without a way to easily convert a more human friendly format bidirectionally without loss of detail.
Some people write their math by hand in LaTeX or other formats, but many use visual tools and draw math similar to drawing diagrams. Then those tools generate whatever source code necessary.
In those scenarios, MathML would be much easier to deal with than most other formats. Also, Presentation MathML support is much easier to implement than full-scale support of LaTeX or other more complete math solutions including Content MathML.
The only people who write math in a drawing program are people who don't do enough math to be bothered to learn it.
Which people?
Everyone I know who uses equations in MS Word abandoned the clicky tools as soon as the pseudolatex entry language became available.
The details as to why are here: http://prodg.org/blog/mathml_please/2015-09-16/MathML%20on%2...!
As things stand, math handling on the web is inconvenient at best and a nightmare at worst.
Some quick points about the comments here:
- MathML as a spec is akin to SVG, it's meant for the browser/machine first, and not for direct human consumption. You don't read/write SVG by hand, and neither you should MathML.
- Calling MathML a "failed web standard" is fine by me, as long as you continue the remark with "the Chrome and IE browsers have failed mathematicians" and "the math-on-the-web developers have failed as a community".