W3C home > Mailing lists > Public > www-math@w3.org > July 2006

Re: Math on the web without MathML (CSS 2.1 rendering for HTML and XML)

From: <juanrgonzaleza@canonicalscience.com>
Date: Mon, 17 Jul 2006 05:55:33 -0700 (PDT)
Message-ID: <3203.217.124.69.242.1153140933.squirrel@webmail.canonicalscience.com>
To: <www-math@w3.org>

Neil Soiffer wrote:
>
> Juan,
>
> Your email has so many misstatements, falsehoods, and quotes taken out of
> context, it is hard to know how to reply, especially since you continue
> to repeat them and disregard, misstate, or misunderstand what people
> have said to you.
>

Maybe I am loosing the whole point, but in that case my criticism would be
simply ignored by people reading this list and i would stand alone in the
net.

If my criticism is not correct, then you would not worry because MathML
will remain unafected and, in a near future, all people will use MathML
for mathematics as today we use HTML for text.

The problem is that you are who is misunderstanding i am saying as will be
noted below.

> <blockqoute>
> In canonical science today, I see that CSS renders equals or even better
> than MathML for examples I tried. For instance, the simple fraction
> renders nice in CSS and distort in MathML.
> </blockqoute>
> <blockqoute>
> Curiously I offered examples of math rendered with MathML and with CSS and
> most of people choosed the visual CSS rendering. I will provide more and
> more examples.
> </blockqoute>
> Assuming you are referring to the examples in [1], David Carlisle pointed
> out in [2] that you didn't install the fonts and ignored the warning that
> the fonts weren't installed.  Hardly an honest comparison!
> Your refusal to admit that this is even a
> problem in your reply [3] is an example of how poorly you understand
> math notation.

1) as I already said in my reply to Carlisle in [1], I did not install the
special fonts because I was comparing pure MathML and CSS (not MathML +
special fonts). Your emphasis remember me XSL folks comparisons of CSS
with full XSL instead _just_ CSS vs XSL-FO or _just_ CSS + JS vs. XSL.

As already said in my reply adding special fonts, the MathML root renders
correct but the CSS rendering continues being *the same*.

2) The usage of special fonts (no designed for the web) is not a good
thing.  This has been addressed in a number of papers and talks.

The Mozilla rendering engine is polluted with CM metrics and future fonts
will need of a rewriting of the full engines. Interestingly, this data is
never commented by MathML folks. I already wrote about all that and cited
two folks with interesting commments in [1].

3) It was claimed from several MathML folks that special fonts ***are***
needed for the rendering because technical motives of rendering math.
Therefore the root cannot be rendered without special fonts at the MathML
side because technical motives.

Well, that is not all correct. i) the CSS approach is able to render the
simple root without the special fonts, and ii) others approaches to
rendering of math (e.g. SVG approaches) do not need of special fonts for
rendering of roots. Therefore, there is no problem to explain to people
that special fonts are not needed in alternative approaches.

Unlikely the MathML (Gecko engine) approach, which need of special fonts
and special version for each new font, the CSS approach will work for any
font (present or future) that users or authors like.

4) Before questioning the honestity of someone, please reply why MathML
folks rudely critize any alternative approach (e.g. Carlisle criticism
"the integral sign is too bold”) whereas the same effort is not addresed
to critize some of rendering of tools cited in the MathML site. Some
MathML software are generating symbols are rendered more bold still
(really the rendering is ugly even for non-mathematicians) but nobody
critize that.

The rendering quality of some SVG-MathML approaches cited in the MathML
site is lower than via CSS is being promoted here, still I never see a
MathML folk critizing the MathML approaches.

Note also Carlisle's emphasis on that the + in the example sited in [1]
was too high in the CSS rendering. Well how can you claim that my
comparison was not honest, whereas you are completely unable to

i) Read i wrote that a+b was rendered using simple version of CSS
rendering, without tokenization (this will be observed once i submited the
code to the blog), but in a more advanced approach yuo can align the + in
a separate way

ii) and recognize that the same criticism to + symbol is not being
adressed to

[http://www.antennahouse.com/product/mathml.htm]

see also

[http://www.antennahouse.com/product/img/mathml_sample.pdf]

listed at the MathML site here

[http://www.w3.org/Math/Software/mathml_software_cat_composition_engines.html#Iantenna_house_xsl_formatter]?

Why the "failure" or "limitation" X is rudely critized when is present in
the CSS approach to render mathematics, but the same X is not even
commented when generated by a MathML software?

Please explain this with great care. Explain to users why the "+" in x + a
/ b done via CSS (remember that can be improved) in [1] can be critized by
a MathML folk, but the "+" in m + n &neq; 0 in

[http://www.antennahouse.com/product/mathml.htm]

see also

[http://www.antennahouse.com/product/img/mathml_sample.pdf]

is not critized. Please explain with great care in what way this is honest
and a comparison CSS vs. MathML instead CSS vs. (MathML + special CM
fonts) is dishonest. Explain with great care why some of software listed
in the MatHML site can offer a rendering quality poor that obtained today
from pure CSS approach but ***only*** the CSS approach is both critized
and strongly rejected.

>
> If you are saying most people choose CSS over MathML for rendering math,
> you are starting with a hypothesis that you have not backed with data.

Pardon? I said "look this screenshots" and asked "what do you prefer?" and
people said.

> Robert Miner[4] gave a long list of users of MathML that you either
> disparage without
> providing meaningful data or by quoting people out of context.  He pointed
> out that
> usage of MathML in large-scale publishing workflows have increased 100%
> per year for
> the last 3 or 4 years.

And you ignore any comment about that. Including other people has said
about the acceptance of MathML off-line and rejection on-line (remember
that MathML was designed for the web).

> These are hard numbers that indicate MathML is not only
> alive, but is thriving.

And you take your own data and ignore any other data pointing in the
contrary way, including Google Trends and 2006 data on statistics on TtH
and TtM dowloads. You also ignore that many people in the WHATWG waited no
support for MathML in next (X)HTML5 and claimed for an alternative
approach, but that data may be of no interest for you and then its
validity questioned.

But whereas I am citing data and statistics from third parties with no a
priori economic interest in MathML, you and Miner are citing data from
Design Science. Data is just a list to consumers and says nothing about
trend or global percentages.

> MathML is used in almost every major math accessibility project these
> days.  [7] gives
> a list of some of them.  Look at the conference proceedings for ASSETS and
> ICCHP for
> more projects.  Your sweeping claims with respect to inaccessibility of
> MathML are
> without basis in fact.

Again another off-topic. Since you carefully ignore that I am critizing
the spreading on the Internet of incorrect presentational code and you
carefully ignore a review of some of the code (obtained from real world) I
am using as illustration. Please what is the accesibility of codes
(extracted from real world) I have listed in canonical science today in
many posts?

At least people working in acessibility programs (e.g. AudioMath) is able
to recognize in public that MathPlayer is limited, or that presentational
MathML is not really designed for accesibility (only content Markup can be
complete) and they the choosing for AudioMath was based in the fact almost
none MatHML tool (none browser) support full content MathML (and full
accesibility) of presentational. You also ignore any other data like for
instance that MathML code is being spreaded in the internet is not using
the special entities for accesibility, are using tricks for rendering
prescripts or tensors, and elements of matrices...

You also ignore the remarks done by external specialists on the
experimental status of accesibility for MathML. Again the analysis from
(some) MathML folks is not balanced.

> parens. However, as Partick Ion showed [9], this trick is currently
> limited to
> Firefox.  Until CSS actually adds properties to render math well (and the
> browsers
> actually add the support), it really isn't a viable option.

But at contrary that you both George and I am able to see strengths and
limitations of CSS, whereas you only can see limitations at the CSS side
with abolutely no criticism on MathML, neither on the spec, nor in current
support of MathML in browsers nor in the code generated from the tools.

We are able to see current limitations with the CSS approach and are able
to say, what CSS properties are today only supported by this browser. For
instance was i who suggested the use of some Gecko moz-CSS extensions to
George some time ago for the rendering of fractions and some other stuff.

However, at my best current knowledge no MathML folk critizes the support
of MathML in Firefox. And one may heard the criticism from external
people. E.g. let me cite Luca Padovani thoughts:

<blockquote>
As a matter of fact, despite of its modular architecture, Mozilla’s
implementation
of MathML suffers from a number of severe problems:
</blockquote>

<blockquote>
Mozilla is not able to fully implement MathML formatting semantics. [...]
</blockquote>

Our approach is much more pragmatic and balanced. We offer an alternative
and people will chose they consider viable in function of their needs.
Many people is today considering viable CSS and not viable MathML in
despite of so many propaganda you devote to the criticism of CSS approach.

Note also as the XML-MAIDEN site is able to recognize limitations of
approach whereas citing bugs, whereas corresponding MathML site devote
more emphasis in supposed advantages of MathML than in real status.

You are also ignoring any other technical comments at respect of rendering
via CSS were said and alternative ways to render matrices. No more I can
do then since you are not hearding.

> Rather than bashing MathML, your time and everyone else's time would be
> more
> effectively used if you spent your efforts working towards improving the
> CSS
> implementations in browsers you care about.  Indeed, maybe you would have
> time to get
> around to showing the
> world how wonderful your solutions are by getting your promised website
> update [10]
> finished and being "the first official body" to use CSS to render math.

Is this irony? What is the problem with alternative approach? If MathML is
so powerfull, render so good, is so popular as you state and the websites
using MatHML are accesible and all that, what is then the problem? People
would masively reject the CSS approach and in a few years it would be just
a historical curiosity...

Why are several MathML folks wasting so many time on bashing the CSS
approach or inventing myths on (they believe) cannot be rendered via CSS
instead promoting the approach, developing a solid CSS-Math module
improving weakness of CSS 2.1 for mathematical rendering and promoting the
CSS approach togheter p-MathML or SVG?

>
> Neil Soiffer
> Senior Scientist                 phone: 562-433-0685
> Design Science, Inc.             http://www.dessci.com
> "How Science Communicates"
> MathType, WebEQ, MathPlayer, Equation Editor, TeXaide
>
>
>
> [1]
http://canonicalscience.blogspot.com/2006/07/rendering-mathematics-in-html-via-css.html
> [2] http://lists.w3.org/Archives/Public/www-math/2006Jul/0003.html
> [3] http://lists.w3.org/Archives/Public/www-math/2006Jul/0007.html
> [4] http://lists.w3.org/Archives/Public/www-math/2006Jul/0054.html
> [5] http://www.w3schools.com/browsers/browsers_stats.asp
> [6] http://www.dessci.com/en/company/press/releases/031216.htm
> [7] http://www.w3.org/Math/Software/mathml_software_cat_accessibility.html
> [8] http://geocities.com/chavchan/temp/matrix.xhtml
> [9] http://lists.w3.org/Archives/Public/www-math/2006Jul/0056.html
> [10] http://lists.w3.org/Archives/Public/www-math/2006Jul/0061
>


Juan R.

Center for CANONICAL |SCIENCE)
Received on Monday, 17 July 2006 13:23:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:12:58 GMT