[whatwg] Mathematics in HTML5

whatwg at lists.whatwg.org

Re: Mathematics in HTML5
Ian Hickson wrote:
> I am not at all convinced that it makes any sense to rely on CSS to
> render  mathematics. CSS simply doesn't have the expressive power to
> obtain  acceptably good mathematical typography, and adding features to
> CSS to  obtain this level of expressiveness would require a huge
> specification  with such a small target domain than nobody would
> implement it.

You state that do not makes any sense to rely on CSS to render mathematics.

MathML versions changed to embrace more and more CSS code whereas
deprecating early MathML markup. A pair of months ago, one of big guys of
MathML asked that changes would be done in MathML for CSS compliance, and
exists interest in a special mathematical module in CSS.

So far as I know the Math CSS module has got problems due to incorrect
design of MathML and apparently has been stopped (maybe waiting a mayor
third revision of MathML markup?).

However, for you, CSS do not makes any sense...


You state that CSS simply doesn?t have the expressive power to obtain
acceptably good mathematical typography.

But MathML peole is very interested in both CSS compliance and a special
CSS Math module.

You claim that does not has expressive power, but you do not support your
claims with facts, and you simply fails to show us where IS the MathML
good typography. I have provided you a sample of many test (even the most
basic) from the official MathML test suite are not passed by Mozilla
Firefox 1.0, the only with native suport after of 10 years. Those test are
passed by George markup, even when it is not using special CSS extensions
for mathematics.

The situation at printing is still poor and people is transforming MathML
documents to TeX before printing it because MathML sucks at printing. You
simply ignore the limitations of MathML specification and the limitations
of browsers implementations due to MathML does not fit in the rest of web
technology and developers cannot offer us good implementations.

You also ignore the limitations of MathML implementation in Gecko
(limitations in table layout, limitations due to font dealing, etc.). Luca
Padovani has written some review on that. You want people use the CM fonts
in Firefox, when CM fonts are not designed for the web.

If tomorrow, I want use the STIX fonts for mathematics I cannot, because
it will be needed a rewritting of the full Gecko engine and adaptation to
the new fonts. For each new font you want install in your computer and
use, you will be obligated to compile the full Gecko engine, prepare a new
version was dowloaded and installed by users. The implementation of new
fonts in George approach is trivial and do not need of new browsers ;-).

But above may be your favourite vision of the web.


You also state and adding features to CSS to obtain this level of
expressiveness would require a huge specification  with such a small
target domain than nobody would implement it.

The additions to CSS are minimal since currently we display most of math
via CSS 2.1 (and even MSIE has recently updated to better support of CSS
2.1). By huge future specification you mean current CSS 2.1.

The adding feature are still needed and there is planned a special CSS
math module for usage with MathML. You worry about adding feature to CSS
for math but this has been scheduled in MathML but you simply ignore it...

Instead adding one or two extensions to CSS can be easily implemented in
browsers over the HTML, XML, CSS base of current developments. You claim
for the implementation in browsers of a new entire language

Two or three addings to current languages and reusing of available code is
?such a small target domain than nobody would implement it?. However, you
vision of future of web is that developers do not implement small
incremental language you wait they implement an entire new language which
do not reuse previous code and therefore the efforts may be multiplied by
3.

You reject *one or two additions to CSS in current base* that would be
easily inmplemented in browsers using available code, experience, and most
of markup.

However, yout wait for full implementation of p-MathML + c-MathML +
OpenMath (since c-MathML is not sufficient) + XML + HTML (e.g. <table> vs
<mtable> etc.) + CSS + MathML <mstyle> + CSS Math module + MathML special
attributes (e.g. mathvariant) + XSL-FO + MathML-FO + DOM + MathML-DOM +
special TeX fonts + special unicode fonts (e.g. STIX).[*]

Interesting, but are not your own arguments against you?

And even when one ignores all trouble, the fact that MathML never will be
fully implemented in browsers because is incompatible with browers, the
fact MathML introduces presentation markup when that is generally
considered harmful, etcetera, one discovers your own great solution to
mathematics in the web is reusing p-MathML (with all its errors and
difficulties) but via special parsing mode.

Then we obtain a serie of astonishing add-ons to above ones[*]:

Implementation of new features to CSS -most of which could be reused for
other purposes- would be substituted (in your vision) by implementation of
XML/HTML parsing model

<tag>  b <tag> is different from <tag>b<tag>

more specific implementation of a MathML parsing mode

<tag>  b <tag> is equal to <tag>b<tag>

more special implementation of a new ?hixie? parsing model

<tag>  b <tag> is different from above ones because

<mrow>a b</mrow> would be understood as <mrow><mi>a</mi><mi>b</mi></mrow>

Even asuming that this was sane and was some rationale, even asuming that
MathML IG accepted this approach (a similar approach was rejected this
years) how would <mrow>b </mrow> be parsed in HTML5?

? la XML?

<mrow>b </mrow>

? la MathML?

<mi>b</mi>

? la Gecko?

<mrow><mi>b </mi></mrow>

? la "hixie"?

<mrow><mi>b</mi></mrow>

At the same time, you are editing a specification relying in a manifesto
encouraging backward compatibility with HTML, DOM, and CSS, but propose a
special markup violating just the three.


Ian Hickson wrote:
>>
>> Ian Hickson wrote:
>> > I would say MathML is not widely used because MathML doesn't work in
>> HTML,  personally.
>>
>> I do not know from where this idea get up. SVG is relatively popular
>
> Relatively speaking, SVG is not popular at all.

I do not see tools rejecting it masively, authors ignoring it. I see
browser developers implementing it. I see it working in websites. Could
you point a single site using MathML (and I said "using" not "misusing").

>> and implemented in many browsers, but the same browsers implementing
>> SVG  are rejecting MathML. They are rejecting because difficulties for
>>  implementation, not because HTML lack of.
>
> MathML was implemented in Gecko years before SVG.

History of Math in the web began in 1994 with many failed attempts. The
first MathML W3C recommendation was published in Apr 1998 with MathML 1.01
revision next year (Jul, 1999). MathML 2.0 arrived at Feb 2001.

Today, most of browsers have rejected MathML support, with Gecko based one
offering us partial limited support of one half the specification.

SVG born in the last part of 2001. That is after MathML 1, MathML 1.x and
MathML 2.0. Today many browsers support it natively and with increasing
interest in improvement of the support (read for example Brendan Eich
words).

> SVG is seeing more implementation work than MathML simply because vector
>  graphics has a greater target audience.

Whereas I agree on that graphics have more importance for general users, I
still can see that MSWord includes both graphic and mathematical
capabilitites.

Moreover, it target audience matters, you would reuse available X(HT)ML,
DOM, CSS code before waiting implementation of entire news specifications
(p-MathML + c-MathML + OpenMath + CSS MathML module + MathML-DOM) most
people think are unuseful. More your novel special ?parsing mode? for
math.

>
>> In fact, I do not know a single criticism to MathML emphasizing the
>> point you state. All public criticism are to design options and
>> technical details independent of host language.
>
> I've received feedback from members of the MathML community to the
> effect  of "I wish I could use MathML, but I don't want to use XHTML"
> (i.e.,  MathML doesn't work in HTML).

Sure does not work? I have seen some people using SVG in HTML.

>> More the rejection from w3c MathML guys that do not want to see a
>> mixture of textual strings with MathML own elements.
>
> The proposal is not to have textual strings mixed with MathML. It is to
> have simply real MathML, with defined parsing rules for getting the
> MathML out of text/html documents, since text/html isn't XML.

Your proposal was <mrow> a + b <mrow>

                    ^       ^
                    |       |
                  markup  string

It is more, my similar proposal used not special parsing mode, just
external XSLT and could be used by any browser with MathML support. Your
proposal would need of a new family of browsers (and if current browsers
are ignoring actual MathML why would they support MathML + your
proposal?). Still my _mixed content_ approach was heavily rejected by
MathML IG and others members of the comunity.

>> I would say, ?partial incompletete support of less than one half the
>> official specification?.
>>
>> Content MathML is not supported, only presentation MathML; of
>> presentation MathML not all tags are supported; of all tags supported
>> not all are working.
>
> Ok, partial incompletete support of less than one half the official
> specification. It's good enough to do Math on the Web. (Heck, I was
> using  MathML in my university work five years ago.) It's far better,
> IMHO, than  you could ever achieve using CSS alone.

Curiously official tests are not passed by MathML native support browsers
(such as Firefox 1.0) are passed by Opera via CSS 2.1. Interesting! It
appears that you are right in that CSS is not competitor for p-MathML, but
just in the inverse!

About "good enough to do Math on the Web" I asume that you mean
mathematics is not searchable, visually rendered in many incorrect ways,
incompatible with DOM and CSS (doing imposible the implementation of full
dynamical online educative documents similar to those Mathematica
notebooks),
structurally invalid and not suitable for liquid layouts, non-incremental
rendering (waiting even 10 or 20 minutes when heavy usage of MathML code),
violating basic guidelines of good web desing (e.g. device independence),
sometimes not interchangable between tools, with incorrect semantics, and
being completely unacessible for people with disabilities. No?

And if I want tomorrow to change font family in the CSS of the website I
would wait until that Mozilla comunity compiles a new MathML rendering
engine adjusted to the new fonts and next I would wait until that my
user/clients dowload and install new Mozilla before update the CSS
font-family.

> If CSS can do this today, then you don't need any extensions to HTML. I
> would highly recommend persuing this in the microformats.org space, using
> the microformats development principles, and publishing a stylesheet that
> then renders the given microformat as high-quality mathematics.

That is you are opened to introduce further changes in HTML5 (including
special parsing mode) for a full implementation of the boring p-MathML;
obiously you are also opened to implementation of extra MathML-DOM, extra
MathML styling (reinventing available styling in browsers), and also
opened to extra CSS MathML module, but completely closed to a few changes
to HTML5 for obtaining a solid, cheap, and working mathematical markup.

I initially offered you several proposals, one cheap was implementation of
a math attribute like a complement to the HTML class attribute, but you
offers us either further changes to embrace a never-working specification
(and violating basic guidelines of this WHATWG), embracing a markup is
ignored or no change in HTML.

I simple dislike several claims here for a better markup in HTML even from
members of Opera, Wiki? and others. You also completely ignore the public
offering of one of main guys of w3c CSS to study the problem.

Great!


Juan R. wrote:

> body> table: CSS rules for text tables

> body> formula> table: CSS rules for text tables

This was a typo, it would be

> body> table: CSS rules for text tables

> body> formula> table: CSS rules for mathematical tables



Juan R.

Center for CANONICAL |SCIENCE)

Received on Friday, 9 June 2006 06:56:03 UTC