- From: Roger B. Sidje <rbs@maths.uq.edu.au>
- Date: Sat, 14 Oct 2006 23:44:26 +1000
- To: "juanrgonzaleza@canonicalscience.com" <juanrgonzaleza@canonicalscience.com>
- Cc: www-math@w3.org, ian@hixie.ch, dev-tech-mathml@lists.mozilla.org

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. The easter eggs-based solutions mentioned in your post are well known, but the push has been for XHTML and be caught up in that "one basket" -- to quote Paul Topping. (What a coincidence with easter eggs...). In fact one could use this kind of logic and also have a jsTeX engine where $...$ is parsed and a bitmap produced and included on the fly as a data:URL with <img src="data:bitmap">. BTW, there are plenty other easter eggs like that in Mozilla. (Mozilla does *much more* than publicly advertised -- just the other day, it was "discovered" that it tolerates <mstyle> in <mtext> and that it supports full compound documents -- way above the confines of the MathML spec). To give you an idea, Mozilla actually supports arbitrary "DOM soup" because malicious attackers can otherwise use removeChild() and appendChid() to attempt to exploit security breaches. (As a corollary of this, Mozilla supports arbitrary "well-formed tag soup", whatever you want to call it from your XML/XHTML glass house.) Since Mozilla is not validating and a decree from W3C can't stop people from feeding all kinds of things to the Gecko lizzard, it has to be designed for the worse. Most people don't probably know that one of the security stress-testings that happen behind the scenes is for the DOM tree to be shaken ("stirred") to death, with a JavaScript progam that continuously uses removeChild() of a random child from a random parent and appendChid() to another random parent, for hours and hours, leading in the end to a "DOM soup" beyond comprehension, where for example a <div> can end up being a child of <mi>, etc. Should this process crash at any point, it would mean that a malicious attacker can exploit the existing breach. By (over)design therefore, Mozilla must withstand any such StirDOM (as the Mozilla security group calls it), and the MathML code is no exception. I regularly have to look at such matters in the MathML side. 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 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. On 10/13/06, juanrgonzaleza@canonicalscience.com <juanrgonzaleza@canonicalscience.com> wrote: > > White Lynx said: > > > It is clear that markup will be widely supported in Microsoft products and > > will play important role in STM publishing. > > And others also. Begin to appear tools for Office XML before launching! > > > But it is unclear what consequences we will get for web and webbrowsers, > > if it will be exported to XHTML+MathML or will appear in XHTML+OMML form > > (and either MathML or OMML will be supported by MSIE) then we can live > > with it, but if we just see bunch on WordML documents on web then it > > will be the end of normal "browsing experience" of any kind, as it > > will end up beyound the browser's scope and will be just passed to > > Office or plugins that handle WordML. > > I read yesterday from Brian that Murray Sargent (the chief of OMML) is > joining to MathML 3. Why do not ask him directly? > > > In this context it is vital to integrate MathML (actually both but we > > apparently have no control over OMML) into web environment, to avoid > > degeneration of web into bunch of WordML (well being XML based it is more > > manageable then PDF, but regardless this it is not the web format) files. > > Agree. > > > But under integration into web environment I mean integration in XML+CSS > > framework, today it is not the time to play with HTML tags, it will not > > give us any new functionality that could help us to be more competitive. > > Agree also! The Roger/Ian experiment is based in the unproven claim that > mathematicians cannot use MathML is mass because is blocked in a XHTML > framework and XHTML is hard. > > The main premise is that if MathML (current version) is introduced into > HTML, then MathML use would expand in exponential way. > > When i ask by data on the claim, i never receive statistics, just beliefs > based in "i receive X mails saying how evil XHTML is". > > Moreover, people can use MathML in HTML for years in _both_ Mozilla and MSIE. > > In my previous post i link a HTML 4 strict page with MathML islands like > > <math display='block' xmlns:m='http://www.w3.org/1998/Math/MathML'> > <m:mfrac> > <m:mn>y</m:mn> > <m:mi>x</m:mi> > </m:mfrac> > </m:math> > > or without prefix > > <math display='block' xmlns='http://www.w3.org/1998/Math/MathML'> > <mrow> > <msubsuP> > <mo>∫</mo> > <mn>-1</mn> > <mn>1</mn> > </msubsuP> > </mrow> > <msqrt> > <mrow> > <mn>1</mn> > <mo>-</mo> > <msuP> > <mi>x</mi> > <mn>2</mn> > </msuP> > </mrow> > </msqrt> > <mi>d</mi> > <mi>x</mi> > <mo>=</mo> > <mfrac> > <mi>π</mi> > <mn>2</mn> > </mfrac> > </mrow> > </math> > > and both are rendered in HTML 4! since HTML 5 claims backward > compatibility, we already got a way to publish MathML islands when you > cannot modify your server MIME. > > The page proves that Mozilla can render MathML in HTML (even if Roger > claim the contrary in Mozilla page). MSIE also can render them. You can > apply styles change color of equations, size, mstyle also works, you can > transform an equation in a link... > > I forgot explain there that final DOM is also a HTML+MathML DOM not XHTML > one since final DOM contains <hr> <br> and so on instead the XHTML forms. > > You can render MathML 2 (and probably MathML 3 also), no need for <none>, > no need for new Ian's syntax, no need for changes in CSS layer, no need > for a fixed m prefix (I checked just now that Docbook mml: also works and > is rendered), no side autoclosing effects, no incompatibility with > MathPLayer etc. > > Therefore, i see no rationale for the HTML 5 experiment. Just a waste of > time. Why all this time and discussion is not devoted to Mozilla bugs, CSS > inline blocks and tables, full formatting semantics, next STIX fonts not > dealed by current TeX engine, slow performance with medium size MathML > docs... one wait minutes before rendering. > > Using the trick from Jipsen, some people who _cannot_ (e.g. free domains > in servers) use X(HT)ML can introduce MathML into HTML 4. It is probable > that script can be optimized and reduced in size. > > This may be seen like a way to 'publish' mathml TODAY if you are limited > to MIME text/html. The trick works for both Mathplayer+MSIE and Mozilla. > > The future way to publish would be a full XML framework (or better beyond > XML limits [e.g. ConciseXML]). > > > Juan R. > > Center for CANONICAL |SCIENCE) > > > >

Received on Saturday, 14 October 2006 13:44:30 UTC