[whatwg] Mathematics in HTML5

Mon Jun 19 05:06:14 PDT 2006

Ian Hickson wrote:
>
> On Mon, 12 Jun 2006 juanrgonzaleza at canonicalscience.com wrote:
>> >
>> > WHATWG doesn't have a position on this -- different contributors
>> have  different opinions, and no clear consensus is being reached as
>> far as  I can tell.
>>
>> It has been taken one! The draft of the specification recommends the
>> usage of MathML for mathematics.
>
> Hm, good point. This wasn't particularly intentional. Fixed.

Ok, people would freely choose languages in function of strengs and
weakness. XML-MAIDEN, MathML, OpenMath, and others would compete in an
equal footing (my experience is many people think that MathML is the
_only_ approach to mathematical markup).

>
>> MathML violates the official possition because is not based in reusing
>>  backward compatibility with HTML + CSS + DOM.
>
> MathML works fine with DOM, and it would be just as possible to convert
> MathML to SVG as it would to convert anything else to SVG (as you
> suggest  below).

Others do not agree on "works fine". I personally see MathML-DOM like a
DOM correction to the errors done in MathML markup (somewhat as
MathML1-style was a correction to the mistake of ignoring available CSS
language; error has been partially solved in MathML 2.0).

Take the case of somewhat as <frac><num>a</num><den>b</den></frac> and
<subform>H</subform>T (and variants). Both encodings are DOM
compliant and can be accessed and manipulated via the standard DOM methods
browsers already incorporate.

Take now MathML versions: <mfrac><mi>a</mi><mi>b</mi></mfrac> and
<msup><mi>H</mi><mi>T</mi></msup>. Those encodings are not DOM friendly,
obligating to introduce special MathML-DOM for accessing, for instance, to
the base (H) of the script structure.

However, I can access to H using the *same* standard DOM methods I am
using for accessing any other HTML or XHTML markup –e.g. the experimental
pop-up navigation menu on the still experimental canonicalscience site-
when I use the alternative encoding is being discussed here.

I am not a specialist on DOM implementations, but I know that MathML-DOM
model introduces special problems to browsers developers due to the
extension mechanism chosen (by inheritance). Problems are *avoided* using
a markup as that proposed by George and others which needs of no special
DOM.

As claimed many times in several places in the internet: w3c MathML WG
reinvented the wheel and did it square.

Moreover, still 2/3 of above summation hold.

Posibility for conversion to SVG does p-MathML completely unnecesary (but
not for c-MathML or HTML5-Math). In that case, I doubt that p-MathML was
supported anymore in future. It appears to me a closed road.

>
>> iii) I am reading many people interested in native support for
>> mathematics in HTML5.
>
> Certainly. The question is how. There have been several proposals. My
> recommendation to those who think it is possible to re-use CSS to get an
>  acceptable level of Math support would be to go through the
> Microformats  process to prove the case.

See my comments on why not microformats and the two links revieving
microformats.

> It doesn't make sense to bless a dozen new tags (or more) to be in the
> HTML namespace (and thus with us for all time!) without first proving
> that  yes, that approach is good enough for mathematicians and
> scientists.

And what better way do you know that providing a mathematical markup on
the final WHATWG draft? Mathematicians and scientists and rest of people
using math (enginneers, students, physicians...) could read the draft and
accept or reject it. You would only waste a bit of time writing and adding
one or two new sections to the current draft of the spec.

Some people here has done a public plea for mathematical markup using (at
least the most part of) George original proposal. They did not a plea for
development of a microformat.

>
>> However, i do not remember of some example that was correctly encoded
>> in  p-MathML with current tools and correctly rendered via browsers
>> cannot  be encoded via George CSS approach.
>
> Stretchy glyphs are one example. You can do basic maths with CSS, sure.
> It's the high-end typography that's the problem.

Sorry, but I cannot agree. In real practice, I do not know of a single
example of MathML you can find at NAG, at Distler blog on string theory,
at journals of math or on Living reviews on relativity (between others)
containing mathematics cannot be rendered via CSS. And I would not call
"basic math" to that on Living reviews on relativity or Distler MUSINGS.

It is more, I am updating a serie of snapshots obtained with my Firefox
browser when rendering MathML and the browsers fails in several cases with
strectchy glyphs. Yes, some examples are passed when dowloading and
installing special fonts, but that is not a sane practice.

However, I know many examples of formulae (in physical and mathematical
sites) are encoded via MathML 2.0 and both structure and the visual
renderings are poor than using CSS (even if special CM and math fonts are
installed in the machine): differentials, integrals, basic chemical
formulae, tensors, and others. I have revised some in my blog but I will
offer more examples in a new round covering mathematical journal, and
educative site, NAG, Elsevier usage of MathML (do you know are not using
the standard but an in-house modification?), and others.

About "Stretchy glyphs" take the case of matrices of different size. Luca
Padovani writes "By the MathML stretchying rules of operators [...] A
quick analysis of the MathML markup reveals that there is no way to
preserve the structure of the formula and still have a ‘correct’ rendering
at the same time."

However, I see no limitation for a fine-tuning of the correct rendering of
a matricial equation on a CSS based approach –I could adjust the heigth of
the pathological matrix via standard CSS rules e.g. adjusting height of
the borders-.

But even if CSS was a 80% technology for math that does not indicate it
was not useful. XSLT is also a 80% technology indeed for the rest of 20%
transformations general languages and specific APIs are better.

HTML-text never was designed for "high-end typography" just for electronic
transmision of information. Most people finding nice MSWord mathematical
rendering (even if mathematicians find it boring when comparing with TeX
quality) would find nice HTML-Math-CSS.

>
>> vi) There is an increasing interest in graphical improvements of CSS.
>> Mozilla Corporation and L. David Baron want substitute SVG
>> capabilities via CSS (March 2006) without duplicating code.
>>
>> [http://dbaron.org/css/css-vg/]
>
> I'm familiar with that, I think I was the first person David showed this
>  to. I'm in the CSS working group as well, by the way. :-)

The I suspect you would agree with me that rendering of mathematics via
CSS (specially when including full graphical support for things as
diagrams, roots, geometry, etc.) has more future that waiting a magical
implementation in browsers of an ugly *presentational* XML markup (MathML)
would be obsolete in a few years.

If Mozilla Corporation and L. David Baron are interested in adding things
as lines, gradients, and paths in CSS they will automatically be
interested (but in an indirect way of course) in the drawing of roots, of
poligons, Venn diagrams, maps, functions, etc. Currently browsers rely on
a special presentational MathML markup needing of special non-web fonts
for drawing the roots but cannot draw nothing of the rest, and the rest is
also math.

>
>> I also would recommend a reading of
>>
>> [http://people.opera.com/howcome/1999/foch.html]
>>
>> since several comments also hold to the w3c idea of serving
>> presentational MathML on the web.
>
> I am intimately familiar with this document too, howcome and I have
> chatted about this many times over lunch...

On that case p-MathML is most harmfull than FO objects still when served
in online documents. Not forget that accesibility of p-MathML is poor that
when you use the old GIF-ALT model.

> Note that the proposal to have Math in HTML in a way that can be
> rendered  using CSS is also a kind of presentational Math and not a
> pure-semantic  Math, so arguing that we shouldn't use p-MathML because
> it isn't semantic  would not be consistent with arguing we should be
> purely CSS-compatible.

That was not my point. I carefully recommended to this list avoiding
introduction of content markup and any semantic discussion since the issue
is more complex than we can discuss here.

My view is that HTML5-Math would focus just on structure. Next that
structure would be rendered via CSS. This is usual practice in HTML and
again we recover backward compatibility.

Yet p-MathML is presentational, violates basic guidelines of web desing,
would be avoided from the web and do not fit into general structure of
structural HTML. P-MathML is a verbose version of the old <center>,
, <tt>, , and the rest of presentational HTML has been
deprecated during last years. I see no rationale for that the same
criteria followed with presentational HTML and XSL-FO may be not applied
to p-MathML also.

For instance, <mfrac><mi>b</mi><mn>2</mn></mfrac> is purely presentational
(like XSL-FO is). Even the tokens <mi> and <mn> are purely presentational
even if *some* tools can extract semantics from it. The fact they are
designed to be purely presentational can be seen in the fact that content
MathML version of above code is
<apply><divide><ci>b</ci><cn>2</cn></apply>; that is, reusing
***nothing*** of p-MathML.

But <frac><num>b</num><den>2</den></frac> is not presentational it is
structural. There is a “section” <frac> with two substructures num and
den. Next frac, num, and den are rendered via CSS. For example num
contains a bottom line can be styled via CSS standard rules (p-MathML, of
course, reinvents the wheel adding his own collection of styles and
attributes). Already in this list a CSS gurú claimed that was a big
mistake (in fact, the absence of support in browsers is mainly due to
mistakes of MathML designers).

>
>> However, official positions from several parties here implied would be
>>  welcomed before. Specially interesting for this WG would be position
>> from browser developers.
>
> Howcome has stated his opinion, I believe; the idea of porting MathML to
>  HTML5 was originally put forward by the Mozilla team. I do not recall
> any  opinions from Safari or Microsoft developers on the topic.

Other stated contrary views to MathML support. Morever, I am not sure if
by "Mozilla team" you mean all the team (including CSS-SVG people) or just
the guy that implemented p-MathML in Gecko in that "strange" (but heroic
in no doubt) way (reusing HTML layout code for <mtable>, introducing CM
font metrics in the rendering engine, very-low performance).

It would be interesting to know users and developers think about idea of
providing new mathematical markup for the web, solving difficulties of
MathML.

Some suggestion for publiciting this debate waiting *all* voices
interested in mathematics (beyond mathematicians and scientists) can be
heard?

Juan R.

Center for CANONICAL |SCIENCE)