From: Tim Bagot <timothy.bagot@keble.oxford.ac.uk>

Date: Tue, 27 Jan 1998 21:52:06 +0000 (GMT)

To: MathML mailing list <www-math@w3.org>

Message-ID: <Pine.OSF.3.96.980127212832.7731B-100000@sable.ox.ac.uk>

Date: Tue, 27 Jan 1998 21:52:06 +0000 (GMT)

To: MathML mailing list <www-math@w3.org>

Message-ID: <Pine.OSF.3.96.980127212832.7731B-100000@sable.ox.ac.uk>

On Tue, 27 Jan 1998, David Wheeler wrote: > On Jan 27, 7:47am, Richard J. Fateman wrote: > > Subject: Re: MathML vs HTML math, vs ??? > >>>HEre is a simple piece of math. f(x+y) > >>> > >>>What does it mean? > >>> > >>>Is it different from f*(x+y) ? > >>> > >>>[If you want to require * for multiplication, much is salvaged, but > >>>not everything..] > >>> > >>>Cheers > >>>RJF > >-- End of excerpt from Richard J. Fateman > > A fair question. > > I think there's a simple answer, however: > "Whatever the MathML defaults say that means". > > Now, I would suggest that the defaults should be > "function f of x+y", which I suspect is also what the > writer would expect. And yes, why not require "*" for multiplication, > it's well-ingrained in users of computers. > Even if you're not used to it, it's trivial to explain. > > If you don't want to see the "*" in printed text, you can > use separate commands markings > to determine whether or not (and when) the "*"'s are displayed and > how they're displayed, in a manner similar to SGML's and HTML's > separation of format and content. > > Note that if a browser didn't support MathML, it would display: > > f(x+y) > > which is easy to explain. Try doing that with the current approach, > in which browsers throw away all the <> markings leaving a garbled mess. > And backward compatibility is important; many people CANNOT change > their browsers at all (e.g. they don't own the computer), > and many users do not upgrade often. Look at the slow pace of Java 1.1 > availability as an example. Alternatively, perhaps we could use some sort of markup which never uses tags to supply characters to display, but only to specify the exact purposes of the characters enclosed. This would still get over the problem, and mean that a browser unfamiliar with it could still, for example, display f(x+y) instead of f*(x+y) for multiplication. A compatible browser would use the element containing f to decide whether it was a variable or a function, and then apply an appropriate style (italic for variable, upright for function). > Now it's likely that such a non-marked-up approach might not be as > "powerful" as the current approach. Fine, use markups when the > defaults don't work. But make it simple for most uses! > > In summary: the current approach is terribly complicated > for humans to use and understand. There's a better way, and many > people have demonstrated various improved approaches. Let's work > to find a better way BEFORE a complicated approach is proposed > as a standard. I don't think it will take too long given the work > that's already progressed. Certainly, a method of putting maths in HTML would be useful as an interim measure before we have XML, and can then use MathML (or even something else), assuming that a standard could be implemented before XML is available. Even when we do have XML, HTML maths might still be worthwhile, especially for relatively simple expressions, since it will be some time before XML is more or less universally supported. Perhaps, some MathML could be included in an HTML document using the OBJECT element, which could then supply as alternative content a version using the non-essential markup described above. Tim BagotReceived on Tuesday, 27 January 1998 16:52:36 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:28 UTC
*