From: <juanrgonzaleza@canonicalscience.com>

Date: Fri, 20 Oct 2006 06:39:03 -0700 (PDT)

Message-ID: <3171.217.124.69.237.1161351543.squirrel@webmail.canonicalscience.com>

To: <www-math@w3.org>

Cc: <rbs@maths.uq.edu.au>, <ian@hixie.ch>, <dev-tech-mathml@lists.mozilla.org>

Date: Fri, 20 Oct 2006 06:39:03 -0700 (PDT)

Message-ID: <3171.217.124.69.237.1161351543.squirrel@webmail.canonicalscience.com>

To: <www-math@w3.org>

Cc: <rbs@maths.uq.edu.au>, <ian@hixie.ch>, <dev-tech-mathml@lists.mozilla.org>

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 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Saturday, 20 February 2010 06:12:59 GMT
*