[whatwg] Mathematics on HTML5

Mihai Sucan mihai.sucan at gmail.com
Mon May 29 12:56:16 PDT 2006


First of all, I'd like to make it clear I am not an expert, not even a  
user, of MathML, (La)TeX(ML) nor of other math-related technologies.  
However, I am a daily user of Mathematica application for pure  
presentational purposes (I need to write mathematical documents with  
nicely rendered fractions, radicals, whatever). I am also a web developer  
with a keen interest for web standads and semantical markup (I know xHTML,  
CSS, JS, DOM, RSS, Atom, etc).

Therefore, please bare with me. Thanks.

I haven't joined the discussion until now because I was too busy.

Yes, MathML is not perfect, and for that matter neither HTML is. From the  
perspective of a "presentational MathML" user I can say I'd be very  
interested in being able to save my documents as MathML or any other  
standards-based format implemented in current major and serious user  
agents (Opera and Gecko - I myself don't consider IE serious). I am  
currently using only Mathematica Notebook documents because MathML is not  
supported by Opera and Gecko's support is not something I consider  
awesome. I personally don't even care about the fact MathML code is  
inefficient since I am not even going to manually write that code. I am  
not saying this is not a problem, yes it is, but not from my POV. If I'd  
like to manually write math code I'd use LaTeX.

The point I am trying to make is HTML tables are highly inefficient, and  
might I add, stupidly used, for designing layouts. Against all this, they  
are used for years already by developers. Why? If they'd write the code  
manually, they'd hate using tables. Same goes for MathML and other markup  
languages (like SVG).

A different take:

Good-enough implementations for MathML would probably make-up for some of  
the bad things in MathML. If implementors can reach an agreement together,  
they could even break the current MathML. If their new ideas would prove  
good, then be sure the W3C will include those changes.

I find interesting the fact XmlHttpRequest is now being defined in a new  
working draft specification by W3C. It was first implemented by IE. Also,  
<canvas> which was first implemented by Safari is now getting more and  
more attention.

Why not do the same with math-related markup languages? Implementors  
should do whatever it takes to get things done, to get things working, if  
the W3C is refusing to do that.

Another different take:
If LaTeX is considered to be the best available language for writing  
mathematical scientific documents, and the best for printing too... why  
not have user agents implement it?

Le Fri, 26 May 2006 16:58:41 +0300, <juanrgonzaleza at canonicalscience.com>  
a écrit:

> I have read with great interest this program and I would recommend
> reconsideration of the role of mathematical markup in HTML5. But I would
> first explain a my position. Initially, I began believing that web
> authoring was "save as" command in Mword. Next I begin to work with a  
> real
> HTML tool and discovered the XML world just next.

Same here, more or less.

> I see with terror how people has been
> criticizing "old" table-layout gigantic pages filled with presentational
> <center>, <b>, and <font> whereas now it is "in" to server to clients a
> giant SVG archive with lot of presentational tags simulating tables,
> paragraphs...
> More headaches became from the XHTML part, specially incompatibilities
> with browsers and search engines, the nightmare of MIMEs, and others.
> Finally I abandoned...

I'm glad now authors are no longer using presentational HTML tags (such as  
font, b, i, tables, etc).

As for SVG, this is an entirely different story.

> But biggest error was try to use MathML. MathML is full of incorrect
> design options and technical holes! Even some MathML author recognizes
> that content MathML was not "well thought" due to lack of agreement on  
> the
> committee.

You entirely dislike MathML. What do you think of OpenMath?

Make your own proposal. Which is the currently available standard you'd  
like implemented? None?

I'd be interested of your Canon (Markup Language).

> 1) Insanely complicated and inefficient. In some cases, I have computed  
> 15
> times more bandwidth and server storage when using MathML than
> alternatives.

Bandwidth is becoming more and more less of a problem. Hard disk space is  
not close to a problem, since it's cheap and everybody who's serious about  
working with lots of data has terabytes storage. I myself have close to a  
TB, and I am not doing anything too special.

Thing is, are we going to stop using HTML because it's not good enough? No.

As for alternatives to MathML, be sure they've got their set of  
weaknesses. MathML shouldn't be trashed just because some people don't  
like it. The specification didn't just reach recommendation suddenly,  
without receiving any positive appreciation and implementations.

> The points "Users should not be exposed to authoring errors" and
> "Device-specific profiling should be avoided" are also violated by  
> MathML.
> For example, rendering of MathML in Firefox is based in specific fonts  
> may
> be downloaded and installed. This has been disapproved. One of problems
> with this approach is that once new STIX fonts available I can use them  
> in
> HTML, also in CSS rendering of math, but I cannot use them in firefox,
> since MathML module would be rewritten, and the full engine recompiled,
> obligating to users to download and install new versions of browser for
> new fonts!!!

IMHO, a good implementation for any math-related web technology must not  
ask the user to download fonts, to install some plugin or anything  
similar. I do not like Gecko for the fact it asks me to download  
mathematical fonts. It should just do as Opera does with their voice  
interactivity module: it asks for permission to download the required  
files for that specific functionality. It does automatically download and  
install everything required. Same should be done by Gecko.

> 7) The possibility for automated searches of math continues being largely
> a myth. I can search E=mc2 in Google today when formula is encoded in  
> 4 and it works reasonably well, but how would I search the formula in a
> MathML search engine?

Your site mentions Dr. Michael Kohlhase. In regards to semantic search  
engines I'd like to show you something very specific:

Math WebSearch - A semantic search engine

I'm not sure if searching math is entirely a myth. This is a recent guided  
research project done by a student of Dr. Kohlhase.

> **************************************
> Proposals (from less to more radical):
> A) Eliminate next text from specification
> "Authors are encouraged to use MathML for marking up mathematics"
> because authors would use more concise powerful and solid markup for
> mathematics.

I don't agree because authors would just use images with no alternate text  
or... they'd even give up adding math to their page. If they don't,  
they'll find a way to use a WYSIWYG editor to generate the borked HTML  
code that looks "perfect" in IE & FF.

> B) Add special math attribute can be used in structural markup. For
> example math="num" would be equivalent to class="num", but using math=
> specific attribute. You can also use the class attribute for other tasks.
> This could be solved if space attributes (2.2.7) are implemented.

I don't like this either. I'd suggest creating a microformat defining a  
profile which assigns meanings to various well-thought class names. This  
would be backwards compatible and could aid with using CSS for styling in  
browsers with no support for the microformat.


This woould be similar to what George is doing now with CSS, but with the  
added bonus of support from the user agent which can help with advanced  
things not possible right now only with CSS.

> C) A more complete approach is providing a set of structural and/or
> semantic tags for usage with HTML5.

Mathematics is a field which is very complex and you cannot dream of a  
simple solution for displaying advanced scientific documents.

ROBO Design - We bring you the future

More information about the whatwg mailing list