[whatwg] Mathematics in HTML5

[Ian Hickson]

On Sun, 18 Jun 2006, White Lynx wrote:
>
> Ian Hickson wrote:
> > Certainly. The question is how. There have been several proposals. My 
> > recommendation to those who think it is possible to re-use CSS to get 
> > an acceptable level of Math support would be to go through the 
> > Microformats process to prove the case.
> 
> What is the difference between writing style sheet for microformat and 
> writing style sheet for XML based markup? There is no difference.

Sorry, I wasn't clear. I meant going the Microformats *process*, not 
necessarily "writing style sheet for microformat". It can be based on XML 
if that is what the Microformats process shows is best.

The point is to show the maturity of your proposal before it is put into 
HTML, because of the next point:

> > It doesn't make sense to bless a dozen new tags (or more) to be in the 
> > HTML namespace (and thus with us for all time!)
> 
> Do you pay any fee for registered element names? ;)

Yes.

It takes a couple of engineers to implement a new tag, typically, and 
probably on average takes them about a week (forty hours). (Some tags take 
months and many engineers, some take minutes for one engineer.) It takes 
about a week also for a QA person to write tests for a new element, then 
another week or two over the next few years to handle bugs in that element 
(again, on average). Let's say a hundred hours. Documentation probably 
takes about three days (twenty four hours).

So that's an average time of 204 man-hours per browser. There are at least 
ten browsers in active development, probably more. So that's 2040 hours.

It takes about ten to twenty hours for a spec editor to write the spec, 
plus an hour for people to review it. Let's be pessimistic and say that a 
hundred people review the spec (for something like HTML, it's probably in 
the thousands really). That's a total time of about 115 man-hours for the 
spec.

It probably takes a dozen people about an hour each to report on the new 
element, plus about another dozen people about an hour to write a tutorial 
for the feature, assuming it's a simple feature. 24 man-hours.

Finally, it takes Web developers a few minutes to read about the tag and 
see if they care or not. Assuming that they don't care (if they do, it'll 
take them much longer), it probably takes an average of one minute per 
developer to read the spec or article about the feature. Let's assume that 
sixty thousand developers look at the feature. That's 1000 man-hours.

Assuming that the people involved value their time at an average of $10 
per hour, that's 3179 man-hours at $10 each, so $31,790 per element name.

These are of course back-of-the-envelope calculations. But hopefully my 
point is clear: we have to be confident that a tag name is worth it before 
adding it to the spec.


> Is lack of mathematical markup in HTML good enough for mathematicians 
> and scientists?

Apparently, GIF images for equations are "good enough", yes, otherwise 
people wouldn't be using HTML for mathematical subjects, which they are.

Naturally, I agree that things could be better -- and indeed a number of 
solutions have been developed to address this (at huge cost to the 
industry, I should point out). It is not clear to me that your draft 
proposal is better than these existing solutions, and it isn't clear to me 
that it is a good idea to throw out those solutions.


> > Stretchy glyphs are one example. You can do basic maths with CSS, 
> > sure. It's the high-end typography that's the problem.
> 
> Yes, but [...]

I was asked for examples of what your proposal couldn't do. I was just 
providing examples. I'm glad you agree that your solution can't do 
everything that MathML (for instance) can do.


> > Given that <canvas> has been implemented in IE6, I have no worries 
> > that an HTML-based Math markup language based on MathML (and creating 
> > a MathML DOM) could be implemented in IE6 as well, if someone wanted 
> > to do so.
> 
> Thus no one wanted to do so?

We haven't specced out such a solution yet. I was just pointing out that 
the solution of putting MathML into HTML5 was not incompatible with the 
requirements of HTML5 working in IE6.


> > However, integrating MathML into text/html would make this imminently 
> > possible, since it would allow one to write a text/html-to-XML 
> > converter that actually took HTML5 markup with Maths, and turned it 
> > into native XHTML with MathML, etc.
> 
> If this is called gradual transition then in the same manner you can 
> gradually switch from LaTeX, ISO 12083 amnd anything else to XHTML. Just 
> write convertor.

The difference is that HTML5-with-MathML and XHTML5-with-MathML would have 
the identical same DOM, same rendering, same everything. Only the 
serialisation is different. It actually would be true MathML, just with a 
(slightly) different syntax.

A LaTeX-to-XHTML convertor would not have that property.

In any case this is a straw man; as I pointed out, it is no longer clear 
that the requirement in question stands.


> 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.


> Mathematicians are kindly asked to use microformats, SVG or whatever 
> else they find appropriate.

Mathematicians have asked me to put MathML in HTML5.


> As we see lack of browser side support is not the reason for lack of 
> mathematical markup in HTML, as even something that can be rendered in 
> browsers via CSS is rejected. Many thanks.

Math is no different in this than any other feature. We have to be 
pragmatic here. Your claim that your proposal is adequate for rendering 
maths is unsubstantiated; I have suggested a process by which you could 
show that it is true.

The same process is being required of at least two other features (namely, 
how to encode personal data into HTML documents and how to encode event 
data into HTML documents), both of which have demand that FAR outstrips 
the demand for mathematical markup.

You will note that I have not put MathML into HTML5 either. I would like a 
better idea of whether that approach would work too, before following up 
on it. 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.

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