HTML/MathML integration

> Could you enlighten me as to what you mean
> about the need for a new syntax?

I think everyone agrees that MathML benefits from the strictness
requirements in XML.  Any "loose" syntax can be considered at best an
abbreviation, and possibly error correction.  But it needs to be there
for the integration.

Strict MathML is already available.  It can even be embedded in HTML
as an object.  To get a tighter integration, it would have to fit in
better with HTML.

HTML, in practice, is much less strict.  Much of the html 5 spec is
taken up specifying how to recover from errors in such a way that the
language will continue to support not just "loose", but "sloppy".  You
may not agree with that, but the browser vendors consider it a
requirement -- otherwise too many pages break, and no one actually
upgrades.

XHTML was (partly) an attempt to get rid of the sloppiness -- and it
didn't work.  Even most pages that claim to be xhtml aren't really
valid.  But browsers support them anyhow.

If you want MathML integrated more tightly with HTML, then it *will*
be treated the same way HTML is treated.

As Robert Miner pointed out, most MathML authors are quite comfortable
using tools (and treating the *ML as the output of a binary step), if
that is needed for compatibility.  In HTML that isn't true.  It isn't
just people who hand-edit (though there are a fair number) or
cut-and-paste without understanding, it is that there are many invalid
tools and templates.

These people won't suddenly fix their whole toolchain to support math.
 The conscientious will just avoid MathML because of the cost of
making the rest of the page valid.  Most people will go ahead and use
it in a simplified, invalid manner, which the various browsers will
correct in different adhoc ways.  That is the worst of both worlds.

So if there is to be an integration, it is better to use a much
simplified model, and specify a common error-correction strategy.

-jJ

Received on Tuesday, 1 April 2008 16:15:30 UTC