[whatwg] Mathematics in HTML5

[juanrgonzaleza at canonicalscience.com]

"Robert O'Callahan" wrote:
>
> I'll speak up as one of the Mozilla layout developers, but speaking only
> for myself.
>
> Since we already have a MathML implementation --- which works fairly
> well in my experience ---

Do you mean structurally invalid, inacessible, not searchable, and
sometimes incorrectly rendered math that one find even at academic sites
using MathML? Do you mean the in-house **modification** of MathML Elsevier
is using but still serving graphics on the web?

Or do you mean that due to specificies of MathML ugly design, Mozilla
layout engine is unable to fully implement MathML formatting semantics?
You may know this point better than me. I am not sure but apparently the
solution to this will be a complete rewritting of the Gecko engine from
zero, that is true?

Or by “fairly well” do you mean an average theorem in the HELM library
takes up 20 minutes to render on a high-end machine? The own Mozilla’s
MathML author has studied this point in detail and traced the problem to
the own MathML layout engine in Gecko.

Also I think (correct me if wrong) that you are talking from a pure
developer view (without many experience in authoring of complicated MathML
docs). In theory, MathML would be able to render something so simple as
{ds}^2. In practice both Distler (Mussing ultra-technological blog) and
Living reviews on relativity online journal (HERMES project) still are
unable to do something so simple as visual rendering of {ds}^2 how I have
pointed many times (aural rendering and accesibility of code is purely
inexistent).

A few days ago, Distler received notification about my open criticism
about one of his multiple incorrect encodings of mathematics on the web
and he changed the code just a few days ago, but now the visual rendering
is poor that using old HTML 3 code.

The point is that there exist very important holes and mistakes in the
MathML specification, and waiting spreading on the web or magical
implementations of the spec. in all browsers does not eliminate the holes
and mistakes.

We are trying to eliminate those problems from the web. In fact anyone
using HTML5 will be able to encode and render {ds}^2. Mussings (claimed to
be the technologically most advanced blog of the planet) is unable to so
simple taks even using: MathML 2.0 + XHTML 1.1 + special DTD + native
browsers + special MIME + special fonts + special plugin + special IteX
dialect.

> I think it makes more sense from our point of
> view to fix/improve MathML than to deal with new CSS extensions to get
> decent rendering.

MathML 2.0 did some presentational features of MathML 1 deprecated. MathML
3.0 probably will do some of current presentational features of MathML 2.0
deprecated. The CSS Math extensions are scheduled by both MathML and CSS
IG and would be implemented in browsers in any case. Therefore, the
fixing/improving of p-MathML looks (in my opinion) as a waste of time.

Moreover, p-MathML violates basic guidelines of web-desing, somewhat as
XSL-FO or SVG do. Mozilla has publicy expressed its interest in adding CSS
extensions for a **semantic** implementation of most of SVG. Those
extensions for vectorial graphics could be reused for rendering math (e.g.
roots): somewhat as today we can render mathematics using SVG without need
for native p-MathML, including stuff that p-MathML cannot render:
geometry, commutative diagrams, chemistry...

> MathML's purported incompatibilities with DOM and CSS
> are not serious from an implementor's point of view, at least no worse
> than lots of other CSS-unfriendly content we have to deal with. I hope
> that the fonts issue gets better when comprehensive STIX fonts are
> freely available online and we can automatically download them whenever
> they're needed.

Mozilla philosophy of adding everything (even incompatible layers) in a
big elephant monolithic module is not popular in other browsers (e.g.
Opera). Therefore...

Is it true that future STIX fonts will need of a significant rewriting of
the MathML formatting engine of Mozilla? Will be we need new versions of
the browser for new font families?

> stronger case for inclusion. I would also like to see a complete
> description of the CSS extensions required for real high-quality
> rendering.

Why do not ask to CSS-MathML module people or even to your own Mozilla
colleagues for the already implemented -moz-math CSS extensions?

>>From my point of view, a <fraction> element that can be implemented
>> using
> inline-block in the UA style sheet seems like a reasonable thing to
> support in HTML5, since it's basically no effort and is a small
> increment over existing <sup> etc.

What one great notice!!!

What do you opine of my suggestion for addition also sub-sup and
under-over constructs to the basic spec?

Both sub-sup and under-over constructs are _basically_ fractions without
the line. Once fractions are implemented in UA, I would wait minimal
efforts for the implementation of sub-sup and under-over.

We could leave away roots (can be still displayed with some effort from
the authors; there are techniques on internet for this) and other
refinemenst until better days.

Authors could reuse HTML or CSS tables for vectors, determinants, etc.


"White Lynx" wrote:
>
> Robert O'Callahan  wrote:
>
>> From my point of view, a <fraction> element that can be implemented
>> using inline-block in the UA style sheet seems like a reasonable thing
>> to support in HTML5, since it's basically no effort and is a small
>> increment over existing <sup> etc.
>
> Thus fractions work in MSIE, Opera, Prince. One of Mozilla developers
> admits that including fractions in HTML5 makes sense. Seems like no
> problems on browsers side. Include them in HTML5 and at least school
> level mathematics will get its place on web.
>
> This is small step but it is still important as torturing people that
> need to include simple formulae in web page with complex machinery
> involving XHTML, namespaces, MathML that requires extra plugins in most
> of browsers,  sometimes XSLT or JS, from the very beginning makes web
> very distructive  for math and not only math folks. So small step in
> right direction makes sense.

People at medical community would be also very happy with that.

[http://www.medicalcomputing.net/action_potentials_code.html]

Specially iluminating is the section "My choice of technology in this
example is driven by several factors:"

This is a point I failed to explain at this list but that a mathematician
working with TeX call "ugly rendering" a biologist, a chemist, or a
physician can find it nice enough.

The rendering of the Nernst equation in above link can be improved (I
personally would do) with a bit of fine-tuning in CSS but many scientists
(students also) will find it nice enough for *the web*.

George available stylesheet would rendering better the equation.


Juan R.

Center for CANONICAL |SCIENCE)