Re: Wish List for New Spec

Rick Collins (
Fri, 5 Jan 1996 01:18:04 -0330

Message-Id: <>
From: Rick Collins <>
To: "'Brian Behlendorf'" <>,
Cc: "" <>
Subject: RE: Wish List for New Spec 
Date: Fri, 5 Jan 1996 01:18:04 -0330

I agree that an independent way of handling equations is far more =
practical.  I'm here at a University where there is some eagerness for =
"math".  Problem is that we've gone this route before with =
wordprocessors and, although the major players implemented it, I dare =
say less than 5% of the application users bothered to use it.  I think =
it's too early in the life of html to devote any percentage of commands =
to the specific math task.  The add-in concept is good.

From: 	Brian Behlendorf[]
Sent: 	Thursday, January 04, 1996 4:53 PM
To: 	Matt Heffron
Subject: 	Re: Wish List for New Spec=20

On Thu, 4 Jan 1996, Matt Heffron wrote:
> >> > Math would be number 1 on my list.
> >>=20
> >> Anyone else who feels that way, speak up.
> >>=20
> >
> >Okay, I will.  :-)
> >
> Me, too.

Sorry to be the sourpuss, but I disagree.  It's not just that it's not=20
high on my list - I fear that the effort to create a maths set which is=20
rich enough to keep the semantics (i.e., being able to drop an equation=20
into Mathematica - hey, can Word do that?) is going to place such a=20
burden on HTML that it'll either be ignored by browser implementors or=20
even create animosity towards the standardization effort.  Instead, I=20
think we should look at the compound document possibilities offered by=20
embed/insert, and create (or look for, if it already exists) another =
type designed particularly for mathematical formula representation.  =
instead of=20

  ...some HTML stuff
  <MATH>(the maths code to represent a^2/b)</MATH>
  ...some more HTML stuff


  ...some HTML stuff
  <INSERT SRC=3D"equation1">a^2/b</INSERT>
  ...some more HTML stuff

Where "equation1" is that separate data type, i.e text/htmaths,=20
application/postscript, application/latex, etc.

The benefits:

1) browsers which can't parse the "equation1" data type can still have a =


2) content negotiation allows for the evolution of the "equation1" data=20
type *separate* from the evolution of HTML

#2 is really important.  The more HTML grows into a kitchen-sink of data =

type amalgamation, the more pressure there is to constantly "rev" HTML =
the separate feature sets need to be enhanced.  I.e., who's to say that=20
the maths support in HTML 3.0 will be "sufficient"?  It would seem to me =

to be a pretty complex data type if it wants to meet a majority of the=20
demands of scientists.  Beyond the complexity is the issue of =
management - if the two are separated, the community of users who care=20
about math support can evolve their standards at the pace they desire,=20
separate from the pace at which HTML levels evolve.=20

More practically, it means that one doesn't have to wait for new=20
revisions of browsers to support that evolution, since EMBEDed (and=20
hopefully soon INSERTed) data can be rendered via plug-ins, while the=20
HTML rendering capabilities are largely tied to the browsers itself,=20
and it doesn't look like that'll change widely soon, i.e. "Can't handle=20
the <BLINK> tag?  Here's the Java code to do so" - though I hear the=20
Guile browser can do something similar.

Imagine if all inlined images on the web had to be directly embedded in=20
the HTML document itself (i.e. <IMG SRC=3D"GIF89alksjef;lhsdkjhafhsklj"> =
I see this as pretty much the same situation.  If a feature set is=20
sufficiently complex, it really belongs in its own data type.


=3D--  =