[whatwg] Mathematics in HTML5

[Ian Hickson]

On Mon, 19 Jun 2006 juanrgonzaleza at canonicalscience.com wrote:
> 
> 1) It has been proven that via Standard CSS 2.1 not designed for math 
> one can render math better than browsers with native support (as Firefox 
> 1.0) and infinitely better than MSIE, Safari, and Opera (rendering 
> natively zero mathml).

I don't think so. In my experience Mozilla renders maths in a way much 
superior to the CSS approach. I'm also not convinced that the CSS approach 
is good enough for people to use instead of GIFs. People want things to be 
pretty, that's why people abuse HTML for layout purposes so much. There's 
no point providing a solution that people won't use -- so before we add it 
to the spec, we have to be sure it will be used.


> > That's not a convincing case for putting everything in HTML5 today - 
> > it's much easier to pick up new ideas later once they have some proven 
> > success than it is to drop stillborn markup which was believed to be 
> > good at the time but failed to solve real world problems. A 
> > microformat for HTML 4 (and even your own XML dialect in its own 
> > namespace for XHTML) seem like the ideal solution as it allows you to 
> > develop a standard but does not add dozens elements from an unproven 
> > technology to HTML 5.
> 
> This philosophy was not applied to the rest of HTML5 spec, no?

Yes. Canvas was only added once Apple proved it was implementable and 
popular, and had documented it. Drag and drop was added based on both IE 
and Safari implementing a compatible API that is used on the Web, and that 
is widely documented. Most of the new elements -- <footer>, <nav>, 
<header>, <menu>, etc -- were based on a survey of over one BILLION 
documents to see what authors were using/needing. The event and personal 
information sections are waiting on feedback and experience from the 
Microformats community. The parsing model is based on extensive 
reverse-engineering of the four most widely used browsers; the browsers 
used in the study themselves were picked based on extensive research. The 
storage APIs were based on experience in the Mozilla community as well as 
internally at Google, as were the features related to content handler 
registration. The editing host section was based on a popular IE 
implementation as well as experience reimplementing that feature in 
Safari, Mozilla, and Opera. The text selection APIs were based on existing 
implementations. The <script defer> and <script async> features were based 
on research of existing implementations and existing practices with those 
implementations, studying the source of popular libraries such as MochiKit 
and speaking directly to browser implementors, as well as based on 
feedback from a group that deploys scripts in a very distributed manner 
which would benefit from such control. The list goes on.


> Ian Hickson wrote:
> > On Sun, 18 Jun 2006, White Lynx wrote:
> > >
> > > Do you pay any fee for registered element names? ;)
> >
> > Yes [...] $31,790 per element name.
> 
> Strange calculations.

Yet, in the real world, we have to worry about such things.


> > Only the serialisation is different. It actually would be true MathML, 
> > just with a (slightly) different syntax.
> 
> Except that your proposal is not MathML compatible because your <mrow>, 
> for instance, is not MathML <mrow>.

My intent is that they would be the same <mrow>, but I admit I haven't 
explained my proposal fully. This is mostly because I am not convinced 
that MathML itself is "good enough" either.

Using MathML has the advantage that it already exists, and so requires no 
mathematical expertise on the part of WHATWG. If we want to invent our own 
language it will take many months if not years, with scientists from all 
kinds of disciplines being involved to get a good language, etc.

Because I don't think WHATWG is an appropriate venue for a task of such 
huge scope, I would prefer if that happened elsewhere.


> > > In other words math proposal is rejected, mathematics in HTML is 
> > > blocked one more time.
> >
> > I have suggested a process by which you could prove your proposal 
> > would work. That is hardly a rejection.
> 
> Some people can read between lines.

There is nothing to read between my lines. I am being as honest and candid 
as possible. There is no conspiracy here. I have given you the exact 
reasoning I have used, I have suggested how you can move forward. I am 
being quite sincere.


> > > Mathematicians are kindly asked to use microformats, SVG or whatever 
> > > else they find appropriate.
> >
> > Mathematicians have asked me to put MathML in HTML5.
> 
> Most of people is rejecting MathML. Many mathematicians are not finding 
> MathML interesting enough for "updating", somewhat as TeX users are 
> ignoring XSL-FO for printing.

I have been told by some that this is because they can't use it in 
text/html. I have been told by others that this is not the case. Without a 
study showing what the real reason is, we are just speculating.


> Moreover, here many people agreed with George proposal and several wait 
> for this kind of approach in final draft. They ask you for not put 
> MathML.

In all fairness, the list seems about evenly split on what should be done. 
There is no concensus on this list.


> What is more, outside from the mathematical community, CSS and DOM 
> developers probably would say you NO for MathML.

Without a real study showing that this is the case, you are just 
speculating. I could say the opposite, it would be as likely to be true.


> > The same applies to any proposal; MathML has at least a proven 
> > implementation that shows that it can be implemented (to at least the 
> > same degree as HTML itself), and that shows that it can be done within 
> > DOM- and CSS-based browsers.
> 
> In rigor also TeX can be implemented in a browser (IBM did) but was not 
> really working and that kind of approach was abandoned for online math.

Which is good to know, and is a datapoint in favour of not using TeX.


> MathML also has been (at least partially) implemented in a single 
> browser but is not working and in next decade probably we remember that 
> browser with native MathML support like today we remember the old IBM 
> browser with native TeX support.

As I said at the start of this e-mail, my experience is that MathML 
support in Mozilla today works quite well, certainly better than the 
incomplete examples I have seen of mathemantics renderered with plain CSS. 
Others on the list have said similar things. If you want to get consensus 
on this, you need to show us that we are wrong. There are many ways of 
doing this; my recommendation would be to use the process described on the 
following page:

   http://microformats.org/wiki/process

...which consists of:

 * documenting the problem

 * documenting prior behaviour, showing examples of existing pages

 * looking at existing solutions and seriously considering each one, and 
   documenting why each one would not be appropriate

 * considering how existing solutions could be re-used wholesale in a way 
   that is consistent with both those solutions and with prior behaviour

It does not consist of making up class names. It's a problem of research 
and documentation, the same research and documentation that goes into any 
feature that WHATWG specifies.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'