W3C home > Mailing lists > Public > www-math@w3.org > April 2002

RE: Embedding MathML into HTML question.

From: Jimmy Cerra <jimbofc@yahoo.com>
Date: Fri, 12 Apr 2002 13:24:50 -0400
To: "'William F. Hammond'" <hammond@csc.albany.edu>
Cc: <www-math@w3.org>
Message-ID: <000001c1e246$f42d1d70$0100a8c0@locutus>
Hey Dr. Hammond,

> MathML is intended for use with the XML form of HTML, not the legacy
> SGML form.
>
> Efforts to reach old user agents should not attempt client-side
> generation of the SGML form of HTML because there are too many
> pitfalls, given the huge zoo of old user agents.

I wouldn't say that HTML4 is 'legacy'; it is still listed under the
"Recommendations" heading at http://www.w3.org/markup .  Further, use of
XHTML is still nowhere near the popularity of HTML4.  MathML will never
(in the short term) achieve widespread use on the WWW while still
limited to use with XHTML and other XML applications.

Besides, I also want to see if it can be done*. :)


> As things are,
> javascript imported live through the network can be used
> semi-maliciously to hijack basic browser functions.  Moreover,
> javascript, again depending on the user agent, can be used to spin off
> a cpu-eating recursion that will force a platform without memory
> protection into the requirement for a reset.

Well, proper coding can help prevent those kinds of problems.  It is an
interesting note that HTML (and possibly XML) also contains a cpu-eating
recursion problem: specifically, when importing external files through
the iframe or object elements, care must be taken to ensure that the
external document doesn't contain any references to the parent
document's file.  XML might also have a problem with this, dealing with
external entities rather than iframe/object elements.  I don't have
enough experience with XML to confirm this, though. :(


> That said, I think that we need to have user agents that can be
> configured to ignore net-served javascript but still use javascript
> that is installed deliberately on the local platform by the user or
> the user's system manager.

I don't know...  Proper coding and providing a good UA supervised
'sandbox' (made infamous by Java) can help prevent most security issues
with JS.  Also, you solution seems to treat a JS prog as a plug-in to
the browser.  I'm not dissing you idea - just pointing out possible
problems.  All in all, I like it, but I'm not a major browser
manufacturer.  :)

---
Jimmy Cerra


P.S. *One reason, that I decided to pursue the crusade, is that I wanted
to create a web site to help people with Calculus and Physics classes.
I didn't like the current methods currently in widespread use on the WWW
for displaying mathematical expressions, so I decided to find some way


-----Original Message-----
From: William F. Hammond [mailto:hammond@csc.albany.edu]
Sent: Friday, April 12, 2002 10:38 AM
To: jimbofc@yahoo.com
Cc: www-math@w3.org
Subject: Re: Embedding MathML into HTML question.

"Jimmy Cerra" <jimbofc@yahoo.com> writes:

> As I wrote in another message, I'm designing a JavaScript MathML
> processor (as an alternative to plug-ins, XSLT and naive rendering) to
> embed MathML into HTML - specifically, versions 4.01 and 3.2.
>
> One problem is how to embed the MathML (an XML app) document into the
> HTML (a SGML app).  The mathematics should be accessible from early
          ^^^^

MathML is intended for use with the XML form of HTML, not the legacy
SGML form.

Efforts to reach old user agents should not attempt client-side
generation of the SGML form of HTML because there are too many
pitfalls, given the huge zoo of old user agents.

> browsers as well as later ones, but the code shouldn't be seen by
> browsers without JavaScript enabled or supported.  I came up with
using
> a input element to "store" the MathML.  Here's an example:

There's also a security concern.

If we're going to get into heavy _serious_ use of javascript, then we
need to beware of extant user agent behavior.  As things are,
javascript imported live through the network can be used
semi-maliciously to hijack basic browser functions.  Moreover,
javascript, again depending on the user agent, can be used to spin off
a cpu-eating recursion that will force a platform without memory
protection into the requirement for a reset.  (At least, I myself
don't know how to get out of these situations with certain user agents
on certain platforms.)

That said, I think that we need to have user agents that can be
configured to ignore net-served javascript but still use javascript
that is installed deliberately on the local platform by the user or
the user's system manager.

                                    -- Bill
Received on Friday, 12 April 2002 13:24:53 GMT

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