[whatwg] Mathematics in HTML5

[juanrgonzaleza at canonicalscience.com]

Ian Hickson wrote:
> On Sat, 10 Jun 2006, White Lynx wrote:
>>
>> Agree. Once conceptual issues will be resolved and WHATWG will clarify
>>  its position regarding math markup, we can return to naming
>> conventions  and if majority prefer brief element names, ISO 12083
>> element names will  be replaced with shorter ones.
>
> 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. This in my opinion is a big mistake because:

i) There exist technical difficulties in w3c mathematical specifications
doing implementation in browsers inexistent or very slow. One only needs
see the variation on different markups proposed for seeing as errors have
been removed. If compatibility with rest of browsers technology is a issue
for next MathML 3.0 then we will see further changes in the language
again.

The slow implementation of MathML in the Internet is not due to a small
target. At the one hand Microsoft is supporting equation editor in MSWord
and providing MathML support in Office whereas rejecting native support of
MathML in MSIE. Also others browsers are not supporting MathML even if
interested in math. Reason is that MathML is not easily implemented in
browsers.

ii) The WHATWG follows an official position stated in the Mozilla and
Opera manifesto. MathML violates the official possition because is not
based in reusing backward compatibility with HTML + CSS + DOM.

iii) I am reading many people interested in native support for mathematics
in HTML5. I also read interest from one of big CSS guys. If I remember
correctly only you have rejected the proposal but providing a novel one is
not backward compatible with nothing.

> Personally I think the best way of demonstrating that no browser-native
> support is required would be for someone to develop a specification for
> mathematics markup using the microformats.org principles. If this
> demonstrates that it really is possible to create viable math markup in
> HTML and have it completely styled in CSS then that would be a good step
>  forward.

You talk of "no clear consensus" (I do not agree, for example nobody is
against the fraction markup proposed by George only about tag names).
Moreover, this thread is still very young. After 10 years the MathML IG
has not achieved consensus still in input sintaxes or so. Would then
MathML to be supported as "microformat" ;-)

Do not forget also that just a weeks ago we discussed how \dot{q} would be
encoded in MathML 2.0 (specification says nothing on this also). There was
three main proposals: usage of <mover> always, mixed usage of <mover> and
Unicode combining diacritics, usage of Unicode always.

Moreover, I added exmaples of outputs for \dot{q} from MathML tools. Each
one offered different mathematical markup, and some of markups generated
failed in interchange with Mathematica 5.2 and one of them (from IteX) was
incorrectly rendered. Therefore after 10 years, we got problems on
encoding of \dot{q}!!!

iv) CSS ampliations for MathML will needed in any case. And, in a future,
all presentational redundant features of MathML would be removed from the
web by consistency.

v) You have done some heavy criticism on limitations of CSS, and
apparently you believe that rendering of math in CSS is kind of impossible
approach

"Things that are impossible just take longer."

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.

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. Then some discussion here
over rendering of roots via SVG fragments would be addressed to rendering
of roots via CSS (just approach George is taking now ;-). If in a future
best ways to render roots in CSS are available he just will update the CSS
,but markup will remain the same and legacy docs will continue working
(with increased quality rendering).

[http://dbaron.org/css/css-vg/]

This class of approach and similar others will do p-MathML completely
unneeded in a near future (with native p-MathML browsers with absolutely
no future).

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.

Once you can map p-MathML to SVG and you can render mathematics on the web

[http://www.w3.org/Math/testsuite/testsuite/TortureTests/Complexity/complex1.xml]
[http://www.grigoriev.ru/svgmath/samples/complex1.svg]
[http://www.grigoriev.ru/svgmath/samples/complex1.pdf]

[http://www.w3.org/Math/testsuite/testsuite/TortureTests/Complexity/complex2.xml]
[http://www.grigoriev.ru/svgmath/samples/complex2.svg]
[http://www.grigoriev.ru/svgmath/samples/complex2.pdf]

do you NOT need specific presentation MathML support anymore because you
can map your own favourite collection of tags. Ah! and most of the SVG
math looks better in my Firefox 1.0 with Adobe SVG 6.0 plugin (pre-alpha
version) that via MathML native rendering. I could provide to you
snapshoots for comparison also in this case.

Moreover, the generic SVG rendering can be coupled to other languages,
once I know SVG code for rendering a fraction I do not need use
<mfrac><mi>b</mi><mn>2</mn></mfrac>. I can use any code I want: including
structural and semantic code. I could even write
<fraction>b<den>2</fraction> in my documents.

And if SVG is rewriten like extended CSS then that would be great, very
great!!

However, the structural (with some semantic) markup of kind is being here
discussed will be ***still needed***. Somewhat as <h1> is needed
independently if you render headings via XSL-FO, CSS, or SVG.

Therefore, since this HTML5 work is for a better (backward compatible)
work can be easily implemented in browsers and inexpensively used by
street people, I carefully recommend further discussion of mathematical
capabilities into HTML5.

However, official positions from several parties here implied would be
welcomed before. Specially interesting for this WG would be position from
browser developers.


Juan R.

Center for CANONICAL |SCIENCE)