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

Hello All.

Juan R wrote:

> Whereas one can see an increasing interest in CSS, including printing
of
> books, there is not such one increasing in MathML. At contrary,
apparently
> nobody want print using MathML and there is a return to TeX bassed
systems
> (MathML to TeX conversors).

This is false.  

Amongst professionals who deal with commercial publication of science,
technical and medical material, the growth of MathML has been steady and
marked.  Based on Design Science sales records, MathML usage in
large-scale publishing workflows has been increasing at around 100% a
year for the last 3 or 4 years.  This data is just as concrete as Ian
Hutchinson's download logs. You can see a selection of some of the
organizations using our tools for MathML in production at
http://www.dessci.com/en/products/mathflow/mf_cust.htm.

In many ways, our data likely gives a better indication of adoption
within the industry than the data about TtM, as TtM is more focused on
end user sales, and primarily end users in academia using TeX (where
most TeX usage is) at that. Keep in mind that Prof Hutchinson is a
physicist, who does TtM on the side as a hobby.  By contrast, Design
Science sales tend to be large, business-to-business sales to enterprise
customers, with ongoing supprt.  These are customers are typically
making major investments to upgrade their publishing workflows to XML.
They are overwhelmingly choosing MathML to represent mathematics.  The
are only a handful of large, serious publishing operations that have
actually switched to XML for their production workflows that aren't
using MathML, and even in those cases, it is mostly because of backwards
compatibility, typically with TeX-based workflows, or in one or two
cases, ISO12083 math.  

It is easy to understand how you would be unaware of what is going on
amongst commercial STM publishers, and indeed, their requirements are
very different from those of the amateur or academic individual wishing
to hand author web pages for consumption of other similar individuals.
I understand perfectly why you are frustrated about the difficulty of
authoring and viewing math in your canoncial science web pages, and why
this skews your viewpoint.  However, from the point of view of
professionals who make their living from STM publishing, display in web
pages is merely one facet, and generally not a very critical facet, of
what they need to produce from their source documents.  

Most of the commercial and enterprise customers we work with place
strong emphasis on storing as much information as possible in their
source documents, to maximize their options going into the future.  They
also prefer mature, standard solutions for which mature, supported tools
exist and that integrate with the rest of their workflow software.  The
central requirement is generally the need to produce high-quality print
output via PDF. Many must deal with accessibility.  Most are interested
in better information retrieval options.  Almost all of them need strong
validation, and maximum flexibility in transforming data for a
wide-range of applications, from online assessment to symbolic
computation.

Thus, from the point of view of your typical STM publisher, the whole
subject of CSS styling of math markup of some kind for display in web
browsers is just one aspect of a much bigger problem.  If George (White
Lynx) is able to get his XML-Maiden stuff to the point where it works
really well on a variety of browsers, and it is reasonably stable and
well supported, that would be interesting.  It would be one of many
output formats that would then be possible options for web display,
along with PDF, HTML+images, jsMath, AsciiMathML and the rest.  Some,
maybe even many, serious content providers would start using it.  

You have implied many times that advocates of MathML aren't interested
in using CSS to render mathematics in web pages.  But that isn't true.
David Carlisle was blazing the trail in this area long before you and
George got involved with it.  Before that, the Microsoft representative
to a previous Math Working Group went to the lengths of hiring a
consultant to look into the feasibility of render math using CSS and
JavaScript in IE5. We have worked closely with the CSS Working Groups
over a period of many years to improve the capabilities of CSS to render
mathematics, have on two separate occasions developed concrete and
detailed proposals.  Similarly, we have worked with the SVG people to
investigate the options for math rendering in browsers, and diligently
investigated other attempts in this area such as jsMath and ASCII
MathML.

But, it is huge leap to claim that XML plus CSS could replace MathML.
Until you can offer the industry a standardized markup language, with
multiple vendors of production capable tools, you don't have a viable
alternative to MathML.  Until you can demonstrate accessibility, online
assessment, and symbolic computation, you don't have a viable
alternative to MathML.  Until you can demonstrate the ability to produce
a variety of output formats from a single source, including professional
print-quality output that can be easily integrated into current
production workflows as well as HTML and XTHML output, you don't have a
viable alternative to MathML.

As I have pointed out consistently and repeatedly, your view of the
requirements for a math markup language are entirely too narrow.  XML +
CSS solutions for rendering math in web browsers have their place as an
output format.  But it simply isn't a serious contender for meeting the
broader requirements for a math markup language, as they actually exist
in the world as opposed to within the limited scope of your canonical
science project. 

If you want to work -- really work -- on improving XML + CSS rendering
of math, then start doing it.  There is plenty substantive technical
discussion taking place on the subject on this list.  Go ahead and work
on really good rendering of scripts and stretchy fences, and all the
other problems.  When there just isn't a way to do something well today,
figure out what changes it would take to CSS and we'll help you take
that to the CSS WG.  As you know, the Math WG and the CSS WG share the
same W3C staff contact, Bert Bos, so it isn't like we don't talk to each
other.  If you succeed, XML+CSS will inevitably become more important
relative to MathML, and you will achieve your goal more effectively than
any number of postings bashing MathML will ever accomplish.


--Robert

Robert Miner
Director, New Product Development

Design Science, Inc.
140 Pine Avenue, 4th Floor
Long Beach, California  90802
USA
Tel:  (651) 223-2883
Fax:  (651) 292-0014
robertm@dessci.com
www.dessci.com
~ Makers of MathType, MathFlow, MathPlayer, WebEQ, Equation Editor,
TexAide ~

 

> -----Original Message-----
> From: www-math-request@w3.org 
> [mailto:www-math-request@w3.org] On Behalf Of 
> juanrgonzaleza@canonicalscience.com
> Sent: Friday, July 14, 2006 9:00 AM
> To: www-math@w3.org
> Subject: Re: Math on the web without MathML (CSS 2.1 
> rendering for HTML and XML)
> 
> 
> Patrick Ion said:
> >
> > Dear Juan,
> >
> > I certainly don't quarrel either with the quotation from 
> Hutchinson of
> > <blockquote>
> > MathML has a number of weaknesses.
> > </blockquote>
> > or, in fact, with the assertion.  Nor is there a problem 
> for me with his
> > <blockquote>
> > My guess is that it won't. But with luck it will gradually 
> become more
> > widespread.
> > </blockquote>
> > That's his prognosis and a benevolent wish.
> 
> But apparently Hutchinson based his guess in three main 
> points: i) Server
> statistics over last 5 years with its TtH and TtM, ii) Technical
> (annoyances) issues of MathML, iii) History of the 
> mathematical markup.
> 
> Whereas similar claims from MathML folks (waiting magical 
> spread of MathML
> on the Internet) appear to be based in faith.
> 
> > I could quibble over how
> > big a niche might be, but I am not clear how MathML could
> > 'take over web mathematics publishing' at the present stage of
> > web technology.  I'm not sure CSS has correspondingly taken
> > over web page styling, though it's a lot wider in scope than
> > MathML as a markup.
> 
> Whereas one can see an increasing interest in CSS, including 
> printing of
> books, there is not such one increasing in MathML. At 
> contrary, apparently
> nobody want print using MathML and there is a return to TeX 
> bassed systems
> (MathML to TeX conversors).
> 
> E.g. last MSIE adds a better support for CSS, whereas 
> continues ignoring
> MathML native support.
> 
> > Where I questioned the attribution to Hutchinson was for
> > the phrasing
> >
> >> we abandon the MathML approach, encourage to all us users,
> >> collaborators, and visitors to abandon MathML,
> >
> > but I now see that perhaps you intended to convey in
> > http://lists.w3.org/Archives/Public/www-math/2006Jul/0028.html
> > not that sense of attribution to IH, but that you wished to 
> correct your
> > typo by
> > us users ==> our users
> 
> Now I understand the confusion. I thought that was clear that 
> I was using
> <blockquote> for Hutchinson's words.
> 
> > So the syntax form of your message was, in outline,
> >
> > Typos ...
> >  > A
> > may read
> > B
> > with
> > C
> > instead
> >  >D
> >
> > and might have been in another notation
> >
> > Typos:
> > A ==> B
> > D ==> C
> >
> > This perhaps illustrates the difficulties of markup without
> > specifications.
> 
> Maybe we would use content MathML 2.0 and prefix notation for 
> efficient
> communication!
> 
> > Are you really proposing to explore examples such as
> > you have in
> >
> >> For instance, the recently
> >> proposed at the HTML5 mailing list
> >> <frac>a<den>2</frac>
> >> also works with CSS, even if is *not* valid xml. Ok?
> 
> No, it was an example of how the same CSS techniques can be reused in
> HTML-XML-SGML (note that CSS-like techniques could be implemented in a
> DSSSL engine thanks to similarity with XSL-FO).
> 
> The point was that CSS techniques are more versatile than p-MathML.
> 
> > Obviously one can work with other markup than valid XML.
> > It just does not seem to me a very good idea in this
> > context today.  Any revision to a MathML spec will have to be
> > consonant with other prevalent W3C specs, I believe, as the
> > previous versions were at their times.
> 
> Agree with requirement on consonancy with other specs but I 
> cannot agree
> with the history.
> 
> It would be not the first time is claimed that the MathML WG 
> reinvented
> the wheel whereas ignored other specs. Hakon Wium Lie, from 
> w3c CSS WG,
> wrote last month,
> 
> <blockquote>
> Historically, it's a common mistake to develop markup systems without
> giving much thought to presentation. [...] Given that CSS existed when
> MathML was created, I think the developers made a mistake by 
> not creating
> a markup language that could be presented using existing CSS 
> properties.
> </blockquote>
> 
> > All the best,
> >
> > 	Patrick
> 
> 
> Juan R.
> 
> Center for CANONICAL |SCIENCE)
> 
> 
> 
>

Received on Friday, 14 July 2006 16:24:45 UTC