[whatwg] Mathematics in HTML5

[juanrgonzaleza at canonicalscience.com]

Henri Sivonen wrote:
> My point was that math rendering tends to be addressed by a guy with   a
> mission rather than companies if the companies decide, on business
> grounds, to prioritize their todo lists differently. For example, TeX
> and Gecko-MathML were both created using the guy with a mission model.

But TeX solved problems. And was rapidly embraced by organizations and
mathematicians. MathML is not solving problems it addressed, and
mathematicians and others are ignoring it.

> For IBM it is about complementarities big time. When IBM funds the
> development of software that doesn't generate a direct revenue stream
> for them, they calculate that such software being inexpensively
> available boosts the demand for what Global Services sells. So to get
> IBM to pay for MathML support in browsers, you need a convincing case
> that the expense would be more than covered by the new business
> enabled for Global Services. (Also, IBM is big enough to experiment
> with stuff like techexplorer without betting the whole shop.)

The IBM TeXML was not very popular because I think was unatractive for
both TeX users and XML users.

IBM TeX rendering browser suffered from technical problems, lack of
unification with web, baseline problems, and others.

> For Design Science it is about complementing their priced products as
> well. Without MathML support in browsers, there'd be no use for the
> WebEQ and the Web side of MathType. Hence, Design Science distributes
> MathPlayer for $0.

Ok, but they are waiting magical implementation in browsers of MathML and
heavy spreading on both on and off-line of MathML. If a working HTML math
was prepared, it could be implemented in browsers with minimal efforts.
They could easily adapt its current tools to the new mathematical markup
and begin to obtain benefits, instead waiting for a miracle from the
MathML part.

Precisely a guy from Desing Science was interested in changes to current
mathematical markup for doing it CSS friendly for a rapid implementation
in browsers.

> MathML support--content MathML support in particular--would be
> complementary to Wolfram's products. Actually, a piece of critical
> code that enabled MathML on Mac in Gecko was contributed by a Wolfram
> employee. (I don't know whether he did it on his own time or on
> company time.) So why isn't Wolfram taking care of getting content
> MathML support implemented in browsers with round-trippability with
> Mathematica? I don't know. Perhaps they feel it is not their
> responsibility. Perhaps they have estimated that Mathematica sales
> wouldn't get enough of a boost because of it to justify the cost.

Or maybe you are -as in the rest of your message- forgotten that MathML
was incorrectly designed.

Some comments from a Wolfram Research guy

+++++++++++++++++++++++++++++++++++++++++

Like presentation MathML tags, content MathML tags are not good at
elementary school math

Human authorable MathML was one of the goals listed in the MathML charter.
Many people felt human authorablility was one of the reasons HTML was so
successful.

Ultimately, the MathML committee couldn’t reach agreement on a input syntax

content MathML was not as well thought out as Presentation MathML. As
evidence of this, MathML2 has many content fixes (deprecates <fn> and
<reln>), and adds some tags that were glaring omissions (eg, <lcm/>).

Content MathML is not really designed for computation. MathML purposely
does not contain an "evaluate" token.

What a MathML application should do when it receives the following is not
defined

<apply> <sin/>
<apply><divide/>
<cn type="constant"> π </cn>
<cn>4</cn>
</apply>
</apply>

Content MathML is closer to the intent of XML than Presentation MathML
[but here some people is arguing for an implementation of latter however]

Style sheets or other means of rendering decide on what it should look
like in much the same way as style sheets are used to decide the font
size, font, indentation, and alignment of a title or section heading.

[Remember that George approach is based in standard Style Sheets]

CSS is the main stylistic engine of Web browsers today. It defines a set
of stylistic changes that all Web−based renderers are supposed to
support. The MathML Working Group is working on getting some of the things
used for
presentation MathML into CSS so that stylistic settings can be used to
render math.

[here some people want just the inverse, nothing of CSS compliance and
full usage of presentational MathML even if they are not correctly
working]

[Functions for completeness]

If an evaluate tag is added, then the semantics would probably be vaguely
defined just as what MathML means today to different systems is vaguely
defined. More precise specification raises all sorts of issues that
probably are not easily supported by current systems.

+++++++++++++++++++++++++++++++++++++++++

“vaguely defined”, “not defined”, “content MathML was not as well thought”
maybe are some of reason Wolfram does not waste time (and money) with
content MathML support in browsers.

> As for XML-MAIDEN, I don't think it solves the problem. Stretchy
> characters are a salient feature of math typesetting and CSS just   does
> not do stretchy characters. In such a case, I think it is better   for
> markup to have rendering features that are not expressible in CSS   than
> to stick with what CSS can do. (You can't specify Web Forms 2.0
> widgets in CSS 2.1, either.)

Is able to render lots of math using available standards, fits in web
standards, fit in WHATWG philosophy, is cheap, and can be extended.

MathML is unable to render all math even with specialized tools, plugins,
fonts, markup style and browsers, does not fit in web standards, does not
fit in WHATWG philosophy, is very expensive, and is difficulty extended.

Ah! And you cannot specify specify Web Forms 2.0 widgets in MathML.

What part of p-MathML could not be implemented in a CSS engine?

>>> It follows that I don't think the slow adoption is *necessarily*
>>> evidence of technical flaws.
>>
>> Then you know nothing of the history of math on the web. I would
>> recommend
>> you begin to revise history from the very beginning: HTML 3 Math, the
>> first draft from the w3c. Attemtp to search why was completely
>> rejected.
>
> Well, from Gecko we know that MathML is implementable at least to the
> degree implemented in Gecko. :-)

That is, using a special module is not integrated in rest of browser
engine, using a rendering engine is “polluted by font metrics”, using a
slow non-incremental rendering -10 or 20 minutes with extensive MathML-, a
implementation is not completely DOM or CSS compliant...

HTML 3 Math never was implemented... do you know the criticism?

> Anyway, just because something doesn't succeed in a decade does not
> mean that there are intrinsic technical flaws. There are other
> possible factors as well, and there are examples of technically
> elegant solution not making it because of unfavorable business
> incentives, externalities, learning effects, etc. It is a big mistake
> to assume that technical elegance is sufficient for success on the Web.

Are you reading messages? It is a big mistake to assume that something
technical vitiated will spread in the web thanks to publicy in journals
and other media.

>> Well, always that anyone say me that math is for some little ones I
>> always
>> reply then why MSWord has an equation editor?
>
> If I am not totally mistaken, the equation editor is licensed from
> Design Science which earlier also licensed equation editors from the
> same codebase for WordPerfect and AppleWorks. The cost of developing
> the equation editor did not need to be covered by Word license sales
> alone. Moreover, if I've understood the business model correctly, the
> light version that is included in the price of a Word license is
> supposed to get the users hooked so that those who find the version
> insufficient go to Design Science and buy the full MathType.

Therefore official reply from w3c of Microsoft is not interested in math
because small number of users is a myth

>> Curiously history says contrary. History says that Microsoft was
>> interested in providing native MathML support for MSIE and initially
>> joined to MathML WG
>
> MS joining WGs doesn't mean that they intend to implement in
> immediate future.

Note the “and” in my message and read the text before the “and”.

>> but due to technical problems they after rejected native support
>
> Do you have a reference for that? Difficulties beyond lacking the
> XHTML infrastructure?

Just personal messages, but I received same reply from other developers.

> By the way, MS is reusing MathML in their XML format for Office 12.
> (ODF also reuses MathML.)

Therefore official reply from w3c of Microsoft is not interested in math
because small number of users is a myth.

>> Mozilla has attempted to support MathML and even most simple tests
>> fail.
>
> Not as far as I can tell. Perhaps your simple is too complicated. :-)

My browser fails.

>> Opera developers were interested in mathematics
>> but not in MathML because thecnical weakness of latter (see
>> comments from
>> developers in the links I provided), etc.
>
> Perhaps I overlooked something, but I followed your links and I did
> not see an Opera layout engine developer saying that MathML cannot be
> supported in Opera on desktop for technical reasons.

Would be interesting heard to a developer explaining like MathML could be
satisfactory implemented into a DOM parser + CSS rendering engine.

>>
>> I think that you simply do not know you are talking here.
>
> TeX4ht can manage some MathML output. It doesn't support any language
> that has not been specified yet.

And the MathML output is structurally invalid, not accesible, not CSS
compatible, and sometimes with wrong visual rendering.

Juan R.

Center for CANONICAL |SCIENCE)