Re: MathML-in-HTML5

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>&#8747;</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>&#960;</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