[whatwg] Mathematics in HTML5
ian at hixie.ch
Mon Jun 19 00:20:25 PDT 2006
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? ;)
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
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
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg