[ga6840]

Agree, we do not include a 4*4 image in HTML by inserting <img><row><col><pixel r="255" b="0" g="128" a="0"> ...... In browser level, I think we should treat math expression as a simple and atom component, and the only benefits to expose DOM/XML/JSON or whatever structural information in webpage is probably you can manipulate/extract info from it (e.g. using Javascript). Do we really need to manipulate a math expression? I think a simple "<math>\frac a b</math>" makes much sense to me. I think it is about the trade-off on HTML granularity.

[dginev]

"Do we really need to manipulate a math expression?"

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.

[ga6840]

What I mean is "really need". In fact, there is also the possibility we want to highlight a portion of an image, copy a subimage, etc, but did our HTML <img> tag designed like the way I mentioned? I am the author of a math search engine OPMES (tkhost.github.io/opmes), the search engine works pretty well without the knowledge of DOM structure of math expression. Actually MathML makes a lot inconvenient during OPMES development, to a degree that I choose not to support it.

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?

[dginev]

So, if you can give me an ill-designed analogy, you think you're making a valid point?

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.

[ga6840]

We can argue all day about if <math> should be like <img> or a <svg>, but I do not think I am wrong about asking whether we really need to manipulate a math expression. I just said "it makes sense to me" to write "<math>\frac a b</math>" does not necessarily mean I stand firmly for making <math> this way. If you think there are cases we need manipulate AND we indeed need to sacrifice HTTP length (Internet transmission time) and simplicity to enable math expression manipulation, that is totally fine. I admit your points and will still argue for my points, I do not believe there is an evident truth for this issue we argue (so as this thread). It is still OK. However, I should point it out I am quite confident in terms of hand-writing "<math>\frac a b</math>" more quickly than other people who use whatever advanced richtext editor they want to write its MathML alternative. You can still doubt how many people want write HTML by hand, but shorter HTML is not bad at everything, many high-volume websites get benefits from it. Think about a very hot math Q&A website in the future, being able to handle a lot request, math rendering computation on client side is a logical solution. In this case, MathJax makes a lot sense. I will agree we can adopt a solution that define short <math> and convert into lengthy MathML at client side, in this case we both do not have to compromise.

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.