- 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>
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 UTC