Re: MathML-in-HTML5

Roger B. Sidje said:
>
> This kind of inconsistency is beyond me. For you, on one hand it is
> perfectly acceptable for anybody and their friends to have CanonML,
> OMML, ASCIIMath, jsMath, etc, etc. On the other hand, it is not okay
> to have MathML-in-HTML5. You should be using your same strange
> arguments across the board.

Unlike MathML-in-HTML5, the discourses of the authors of those projects
appears to me to be rather consistent.

MathML-in-HTML5 does not solve integration and design issues of MathML at
the browser side.

The MathML-in-HTML5 presented to us is adding new problems,
incompatibilities, and unnecesaries complexities. As Paul Topping nicely
pointed, there is an inconsistency from Mozilla side, since stuff that
years ago was rejected as being not viable now is being actively endorsed
[1].

A few days ago Anne claimed that the ‘experiment’ _is_ MathML because is
<q>MathML from a DOM point of view</q>. But then she would just as opine
that ‘(a+b)/2’ is also MathML from a DOM point of view (ASCIIMath
generates the corresponding MathML DOM)!

Now she goes more funny still and states [2] that MathML is not a XML
application somewhat as justification for integration in HTML5!

A day, Ian Hickson promotes that we could merge MathML into text/html HTML
if we wanted to reuse MathML, adding "and I suggested some things we could
do to make MathML markup simpler if we wanted to make it easier to author
without sacrificing compatibility with MathML".

Other day recognizes "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.

<none>, <mrow> instead <mrow/>, <msup>c 2</msup> &InvisibleTimes ...
nothing of that neither MathML nor 'true MathML'.

One day he sounds like actively promoting MathML code into HTML5. Other
day says:

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

Several times i heard "Mathematicians have asked me to put MathML in HTML5."

I doubt that lack of sucess of MathML on the web was related to XHTML and
asked many times for statistics or data supporting that. The reply i
received was:

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

Distler appears to support the idea that XHTML is hard and MathML in HTML
is a good idea but in other ocassion he claimed:

"It's not moot, it's simply irrelevant to what *most* people want to do
with (X)HTML. Those who care about the *technical* benefits of using XHTML
care about MIME-type issues. For the other 99% of the web-authoring
population, MIME-types are irrelevant and only reason to prefer XHTML over
HTML is that the former has a simpler syntax, presumably making it easier
to learn to author *correctly*."

A week i read that MathML into HTML 5 would _be_ compatible with MathML in
HTML. Other week i read, "I said HTML compatible XHTML is a myth."

and

"It is a simple fact that a valid XHTML1 document can never validate as
HTML4, and vice versa. That is all that 'HTML compatible XHTML is a
myth' means."

Do you see that kind of erratic behavior in projects you cited above?

Why is all the experiment called MathML-in-HTML5 if is not W3C not WhatWG
initiative? Can Mozilla people modify public initiatives? I suspect that
Opera, Microsoft, and Safari will be uninterested in this project, what is
then its real benefit for users/developers?

In my opinion, the whole experiment would be called
"Math(T)ML-in-Mozilla-propietary-extension-of-HTML5" or so, remembering us
the old days of Netscape-HTML+ and Microsoft-HTML+ propietary extensions
to public standards.

Note, I am not saying "no" to experimentation at Mozilla. You missed my
message.

What I find _unaceptable_ is the usage of public names for private
lunches.  You guys are promoting is not MathML.

I also find technical difficulties with proposal –I cited some stuff easy
to see- and disagree on that this experiment would generate any practical
advantage. Even Ian’s special syntax for mi-mo-mn soap does not reduce
verbosity of MathML in an order of magnitude and even could generate more
verbose archives still as shown here.

> I am afraid I don't have the cycles to be discussing this thread
> forever. I have to move on with a resolution that doesn't add undue
> complications since it clearly appears that no one solution is going
> to satisfy everybody. At this point the simplest <math>...</math>
> seems to be worth retaining for further experimentation (remembering
> ironically that one can use some of the tricks that Juan happily
> mentioned below to map from one form to the other :-).
> ---
> RBS

I cited the tricks with the aim to help to the small subset of users who
are blocked in a HTML 4 framework today. People will masively move to a
XML framework in one or two years thanks to Microsoft. The HTML5
initiative appears to be a bit anachronistic even before being born.


> PS: You mentioned the slow speed. Ironically, you don't seem to be
> aware that XML/XHTML also shares the blame for this. Why? How do you
> know that <html> is well-formed? You can't XSLT such a document until
> you load all of it a-la-FTP to see (or not see) </html> and decide
> whether to issue the fatal ill-formed error that the XML spec
> requires. (How do you know that there isn't an XSLT transformation?
> There may not be any sign of it in the source, but a <?processing
> instruction> may be coming up through a pending JS -- so things are
> often not quite as trivial as you seem to be sitting on your high
> horse and thinking). Hence so far, XML/XHTML documents are downloaded
> in full before a single line is displayed. Contrast this with HTML
> where incremental display gives this impression of fast display.
> Fortunately, some work is going on in Mozilla to improve at least the
> display of XML documents that won't be transformed (c.f. bug 18333,
> following the groundwork of bug 64945). These improvements might show
> up in Firefox3.

I would not call ironic to the fact that you do not seem to be aware that
the XML/XHTML specs do not prohibit incremental rendering.

Mozilla and Safari both lack incremental rendering for XHTML, but this is
usually considered to be a bug.

If you read carefully I wrote, you can see that my emphasis was the very
slow performance of -and only of- Mozilla MathML rendering engine. Of
course, I am not the first noticing this; nice reading that of Luca
Padovani:

"Performances of MathML rendering are not acceptable in some cases. Because
there is just a minority of documents with embedded MathML markup, it is
hard to say how representative these cases are, and what will be the typical
mathematical document on the Web in the future. For sure, Mozilla is not
an option for the mathematical library provided by HELM and MoWGLI.
These days, on a high-end machine, an average theorem in the HELM library
takes from 10 to 20 minutes to render in Mozilla. [...] The same documents
rendered by GtkMathView take from 2 to 3 seconds, also achieving a higher
quality rendering (using the same fonts)."

So far as I can see the project for MathML-in-HTML5 addresses none of
difficulties and troubles with implementation of MathML in Gecko engine
less still addresses the integration issues, or the difficulties with
content markup. Correct me if wrong but the introduction of MathML in
HTML5 will not improve rendering speed, not formatting semantics because
relying on Mozilla HTML table layout engine, no?

My advice was that users would be happier and would acknowledge you if
time and effort is devoted to some of today problems i cited with Mozilla
rather than introducing new inconveniences when playing with nonessential
experiments leaving us nowhere in mathematical markup.

In fact, William F Hammond reports a new problem with last update of FF 1.5

[http://lists.w3.org/Archives/Public/www-math/2006Oct/0115.html]


Juan R.

Center for CANONICAL |SCIENCE)



[1] [mozilla.dev.tech.mathml -- Message on Oct 3 2006 8:27 am]

"This all sounds vaguely familiar. When MathML (and Mozilla) were new,
many of us argued for MathML support in Mozilla's HTML parser for many
of the same reasons I see here. We were told by the Mozilla chieftains
that this would only happen over their dead bodies and that XHTML was
the only way we were going to get MathML support. Perhaps it did take us
7 years to get IE to work with a XHTML+MathML but IE has also had a
solution for MathML embedded in HTML for even longer."


[2] [http://annevankesteren.nl/2006/10/mathml#comment-5699]:

"Rob, I don’t really see MathML as an XML application. More as a
definition of how to render a certain DOM subtree. The way to get to that
subtree has been XML so far, but it can be done by other means, as
indicated."

Received on Friday, 20 October 2006 13:39:48 UTC