<!DOCTYPE article SYSTEM "gellmu.dtd"><article>
<base>href="http:<sol/<sol/www.albany.edu<sol/<pct/7Ehammond<sol/gellmu<sol/webmath<sol/"</base>
<surtitle>Copy of Mail List Article by William F. Hammond</surtitle>
<title>Math on the Web</title>
<author>William F. Hammond</author>
<address>Dept of Mathematics <amp> Statistics<brk/
         University at Albany<brk/
         Albany, New York <spc/ 12222</address>
<email>hammond<atc/math.albany.edu</email>
<date>Monday, August 17, 1998</date>

<body>
<parb>
<anch><op0>href="http:<sol/<sol/pages.nyu.edu<sol/<pct/7Emsh210<sol/"</op0><ag0>Michael Hamm</ag0></anch>
<quostr><ltc/msh210<atc/nyu.edu<gtc/</quostr> writes to <quostr>www<hyp/math<atc/w3.org</quostr>:

<quotation>
Do any browsers (esp. any versions of Mozilla or MSIE) read the HTML3
MATH tag and the tags that go in it<eoq/  Which<eoq/  Thanks<eos/
</quotation>
<parb>
In a single word, the answer is <bold>no</bold><eos/
<parb>
<abbr>HTML</abbr> 3.0 was a
<anch><op0>href="http:<sol/<sol/www.w3.org<sol/MarkUp<sol/html3<sol/CoverPage.html"</op0><ag0>1994
<abbr>W3C</abbr> draft</ag0></anch> that never got beyond draft stage
and was quickly superseded by
<anch><op0>href="http:<sol/<sol/www.w3.org<sol/TR<sol/REC<hyp/html32.html"</op0><ag0><abbr>HTML</abbr> 3.2</ag0></anch>
and, later,
<anch><op0>href="http:<sol/<sol/www.w3.org<sol/TR<sol/REC<hyp/html40<sol/"</op0><ag0><abbr>HTML</abbr> 4</ag0></anch>,
which contain
no provision for mathematics<eos/  (Well, one may use <qquostr><ltc/applet<gtc/</qquostr> or,
better, <qquostr><ltc/object<gtc/</qquostr>; but that does not really give mathematics
fully reasonable access to the web.)
<parb>
Subsequent to the demise of math<hyp/in<hyp/html <abbr>W3C</abbr> formed an <abbr>HTML</abbr>
Math Working Group whose work led to the creation of <abbr>MathML</abbr>, which
is now a <anch><op0>href="http:<sol/<sol/www.w3.org<sol/Math<sol/"</op0><ag0><abbr>W3C</abbr>
recommendation</ag0></anch> with principal rendering implementations
available currently through (1)
<anch><op0>href="http:<sol/<sol/www.webeq.com<sol/"</op0><ag0>WebEq</ag0></anch>
applets under mass market browsers, (2) the <abbr>W3C</abbr> testbed browser
(and point<hyp/and<hyp/click authoring tool)
<anch><op0>href="http:<sol/<sol/www.w3.org<sol/Amaya<sol/"</op0><ag0>Amaya</ag0></anch>,
and maybe (I am not up to date)
<anch><op0>href="http:<sol/<sol/www.alphaworks.ibm.com<sol/formula<sol/techexplorer"</op0><ag0>IBM's
TechExplorer</ag0></anch><eos/
I believe that the source code for Amaya is available for those who wish
to amend it<eos/  (For that matter I believe that all of the <emph>relevant</emph>
source code of
<anch><op0>href="http:<sol/<sol/www.mozilla.org<sol/"</op0><ag0>Mozilla</ag0></anch>,
the public version of
<anch><op0>href="http:<sol/<sol/www.netscape.com<sol/"</op0><ag0>NetScape</ag0></anch>, is available
now, too<eos/  I believe that WebEq and TechExplorer are proprietary with
temporary free trials.)
<parb>
While I understand and accept the reason for the exclusion of the
HTML 3.0 math tags from <abbr>HTML</abbr>, we have been left with a situation
that still presents a serious barrier to the <emph>efficient</emph> flow of
(unstyled) content<hyp/level mathematical
information through the web to robots, small<hyp/screen displays,
audio streams, and Braille streams<eos/
<parb>
For mathematics on the web, there is a sense in which one can say that
there has been very little progress in the last 5 years since it became
possible to have network browsing tools, both under <qquostr>http</qquostr> and
<qquostr>gopher</qquostr>, quickly spawn external applications based on
<quophrase>mimetype</quophrase><eos/
<parb>
It is unclear how much improvement will arise as things evolve from
the dawn of <abbr>MathML</abbr><eos/  My guess is that <abbr>MathML</abbr> will serve
the needs of the mathematical, scientific, and engineering
communities, while still permitting the loss of much of what
we understand as <quophrase>content</quophrase> from many resources on the web
when that <quophrase>content</quophrase> is mathematical in nature<eos/  Of course,
provision for these considerations exists in <abbr>MathML</abbr><eos/
The question is how much attention will be paid to it due to the
fact that it is more expensive to handle<eos/
<parb>
For example, I think that it could very well develop to be at least
10 years before mathematical content can be searched through major
web indexing and cataloging sites in any remotely robust way, while
a great deal more would be possible more cheaply if a <bold>few</bold>
additional arrangements were made for dealing crudely but faithfully
with mathematical content in basic <abbr>HTML</abbr><eos/
<parb>
The arrival of the <quophrase>bazaar</quophrase> model of development in the
<anch><op0>href="http:<sol/<sol/www.mozilla.org<sol/"</op0><ag0>Mozilla Project</ag0></anch> gives
one hope that this will happen<eos/
<parb>
The early long term plan, as I have understood it, of the
<abbr>MathML</abbr> group was to rely on the implementation in mass market
browsers of the type of client<hyp/side processing that is associated with
<anch><op0>href="http:<sol/<sol/www.w3.org<sol/XML<sol/"</op0><ag0>eXtensible Markup Language
(<abbr>XML</abbr>)</ag0></anch>, and, in particular, a type of <abbr>XML</abbr> that
might be called <quophrase><abbr>HTML</abbr> extended by <abbr>MathML</abbr>
(presentation tags)</quophrase><eos/
<parb>
The idea of <abbr>XML</abbr> is to make up your own <abbr>HTML</abbr><eos/  The author
or publishing house makes up a set of tags<eos/  Then he, she, or they work
very hard to create <quophrase>rendering information</quophrase> about these tags
in a <quophrase>style sheet</quophrase> language<eos/  A web<hyp/served
<abbr>XML</abbr> document contains a reference to the corresponding style
sheet, which is also available, under a style sheet mimetype, on
the web<eos/  Browsers are supposed to be able quickly to digest the style
sheet information and then quickly render the <abbr>XML</abbr> document<eos/
(The style sheet information may already be cached.)
This is the <abbr>XML</abbr> dream<eos/
<parb>
The first rendering efforts with <abbr>MathML</abbr> were applet<hyp/based and,
I believe, early <abbr>MathML</abbr> planning envisioned the creation of a
mimetype for <quophrase><abbr>HTML</abbr> extended by <abbr>MathML</abbr></quophrase> and
the creation of an independent rendering application (whether plugin
or external) with specific knowledge of this markup language<eos/
<abbr>W3C</abbr>'s Amaya appears to have <quophrase><abbr>HTML</abbr> extended by
<abbr>MathML</abbr></quophrase> as its default language<eos/
(I don't know the details of Amaya.)
<parb>
The <qquostr><ltc/object<gtc/</qquostr> tag approach to <abbr>MathML</abbr> probably is more
sensible for the long run than <quophrase><abbr>HTML</abbr> extended by
<abbr>MathML</abbr></quophrase> if only because <abbr>MathML</abbr> is so much more granular
than <abbr>HTML</abbr><eos/  If I think about type<hyp/setting <abbr>MathML</abbr>, I tend
to perceive that task as not any easier than that of local direct setting
of <anch><op0>href="http:<sol/<sol/www.ee.latrobe.edu.au<sol/<pct/7Egt<sol/tex<hyp/soft.html"</op0><ag0>
Geoffrey Tobin's</ag0></anch> <abbr>DTL</abbr> (printable ascii equivalent of
<abbr>DVI</abbr>)<eos/  The point here is that setting <abbr>MathML</abbr> is probably
too much to ask of native rendering by mass market browsers though it
is certainly in scale for plugins and external apps<eos/
<parb>
There is still an issue in the eyes of some, on which I am neutral,
of whether there is, or will be, a widely used style sheet language
that is rich enough to provide the desired level of rendering of
<abbr><abbr>MathML</abbr></abbr> presentation tags<eos/
<parb>
We need all of the good relevant plugins and external apps that the
community has the energy to provide<eos/  Still, because these make more
demands on the client side (than do ordinary browsers) <pdash/ demands that
are not reasonable in some places and situations that are and will
continue to be important <pdash/ we need to have a way to handle math
on the web in formats that are very different from paper or "windowing"
terminal displays without loss of <quophrase>content</quophrase><eos/  This is possible
and really not that difficult<eos/
<parb>
Even if one wishes to set aside the need for audio, Braille, indexing,
and searching streams, envision, for example, going as a visitor to
look up something on the web in the San Francisco public library<eos/
All of the windowing stations are tied up<eos/  But you find simple terminal
(<quostr>vt100</quostr>) access to the network via the browser <qquostr>lynx</qquostr>
at a station that is available<eos/  It may be that the savvy library
administrator has that station there because he knows that it
will give <emph>you</emph> a way to avoid waiting<eos/  (In fact, if its processor
is fast, that is almost certainly true.)
<parb>
In <quophrase>windowing</quophrase> situations it is <bold>not</bold> too much to ask for
the <quophrase>mathematical typewriter emulation</quophrase> (<abbr>MTE</abbr>) standard
in mass market browser native rendering as part of native <abbr>HTML</abbr><eos/
<abbr>MTE</abbr> is just emulation of the mathematical typewriter prevalent
in all mathematics departments during the period 1960<hyp/1980<eos/  One had
lots of symbols (in a fixed font), one could underline, one could move
the paper for crude cursor positioning, one could make make something
bold by re<hyp/striking after a slight horizontal displacement<eos/
It was crude, but it preserved content<eos/  Photocopy images of MTE
documents were widely circulated as informal publications<eos/
<parb>
<abbr>MTE</abbr> is more <quophrase>in scale</quophrase> with ordinary <abbr>HTML</abbr>
than is <abbr>MathML</abbr>, which is much closer to fussy typesetting<eos/
<parb>
All that needs to be added to basic <abbr>HTML</abbr> is:

<enumerate>
<item>  <bold>the horde of character entities</bold>
that we need (in scalable fonts with <emph>algorithmic</emph> styling for bold,
emphasis, and perhaps also several forms of alternate<hyp/emphasis)<eos/
Algorithmic styling is desirable for efficiency even though it is less
beautiful than separate fonts; but, for that matter, rendered
<abbr>HTML</abbr> is already less beautiful than TeX rendered by "xdvi"<eos/

<item>  <bold>a simple element <qquostr><ltc/lg<gtc/ ... <ltc/<sol/lg<gtc/</qquostr> (logical group)</bold>
with attributes for horizontal and<sol/or vertical cursor motion,
described by a numerical multiplier relative to the size of the
current font, prior to the display of the contents of the element and
also with attributes for horizontal or vertical stretching, again
described by a numerical multiplier relative to the size of the
current font<eos/  Client rendering support for stretching should be
optional<eos/  Client rendering support for positioning should be mandatory
in windowed displays and where that is not appropriate the protocol should
be to replace the opentag <qquostr><ltc/lg<gtc/</qquostr> by the ascii character
<verb>"<lbr/"</verb> and the closetag <qquostr><ltc/<sol/lg<gtc/</qquostr> by the
<quophrase>balancing</quophrase>
character <verb>"<rbr/"</verb><eos/  (An attribute of the <qquostr>lg</qquostr>
tag could be used to change the crude rendering strings
<verb><quo/<lbr/<quo/</verb> and <verb><quo/<rbr/<quo/</verb> to other ordinary
string values including empty ones<eos/  Attributes could
also be used to furnish hints to computer<hyp/algebra systems or to
furnish the identity of a <abbr>MathML</abbr> tag from which the current
<qquostr>lg</qquostr> was fabricated<eos/  So <abbr>MathML</abbr> could be reconstructed<eos/
Of course, all of this would be authored in generalized <latex><eos/
<spc/ <verb><cln/<hyp/<rpr/</verb>)

<item>  <bold>elements</bold> <qquostr><ltc/math<gtc/</qquostr> (paragraph level) <bold>and</bold>
<qquostr>displaymath</qquostr> (block level) in which

  <itemize>

    <item>  the new <qquostr>lg</qquostr> tag is permitted<eos/

    <item>  all character level things are
rendered one at a time with inter<hyp/word spacing <bold>except</bold> for
the case of strictly alphanumeric character level things inside
<qquostr>lg</qquostr> tags containing no whitespace, which will be assumed to
symbols that might be given <verb>"<bsl/mbox"</verb> treatment in <latex><eos/
  </itemize>
</enumerate>
<parb>
My understanding is that eventually the horde of characters and cursor
movement will be possible with <qquostr>w3<hyp/mode</qquostr> in
<anch><op0>href="http:<sol/<sol/www.gnu.org<sol/"</op0><ag0>GNU Emacs</ag0></anch>
under a windowing display<eos/  (I do not know about algorithmic styling.)
<parb>
Inasmuch as there are very few <qquostr>vt100</qquostr> terminals extant that
are not running in displays under local platform windowing systems,
it is reasonable that the scientific and text<hyp/processing communities
join in an effort to promote a broader collection of characters,
cursor positioning, and algorithmic styling in enhanced <qquostr>vt100</qquostr>
terminals<eos/

</body>
</article>
