[whatwg] Mathematics in HTML5
ian at hixie.ch
Mon Jun 19 13:56:27 PDT 2006
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
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
...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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg