Re: <math>, <fig>, ... (fwd)
Brian Behlendorf (brian@organic.com)
Tue, 21 May 1996 14:42:22 -0700 (PDT)
Date: Tue, 21 May 1996 14:42:22 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>
To: Michal Young <young@cs.purdue.edu>
Cc: www-html <www-html@www10.w3.org>
Subject: Re: <math>, <fig>, ... (fwd)
In-Reply-To: <v02140b03adc7dc1478ee@[128.10.9.72]>
Message-Id: <Pine.SGI.3.91.960521142244.19927U-100000@fully.organic.com>
On Tue, 21 May 1996, Michal Young wrote:
> At 11:49 AM 5/21/96, Brian Behlendorf wrote:
> >Am I a pariah for thinking that the functionality which <math> hopes
> >to encompass would be much better suited to a different data type
> >altogether, embedded in HTML using <object> rather than trying to
> >squeeze it into HTML proper?
>
> Plausible, but one would need a little more detail of a design to judge the
> advantages and disadvantages.
There are existing formats, such as TeX, LaTeX, whatever data format
Mathematica can use, GIF's, etc. Some of those are high-level, some are
just a bunch of pixels without structure. If existing data formats are
insufficient, then whatever effort is going into the <math> proposal
could be aimed towards a stand-alone DTD. In my mind it's clear that
HTML doesn't need <math> to be successful - the question is does <math>
need anything from HTML. Is it important to be able to put a form inside
a derivative equation? Or a <BR> in a formula? I don't think it is. I
think the only thing existing mathematical representation languages might
be missing is a hyperlink ability, and adding that on top of an existing
language might be a lot less work than inventing and refining a new
language.
When we started the VRML project, it was obvious that it was not
appropriate to try and create new HTML tags to represent 3-D objects.
An SGML basis may have been appropriate, but we chose a different path in
the end, extending an existing language (SGI's Inventor) to meet our
needs.
There must be some criterion which people ask themselves when they
consider the question "is it appropriate to put the functionality of 'X'
within HTML?". My criterion happens to be pretty conservative, mostly
because turning HTML into a complex beast (which it's 90% of the way
there) would be the best way to kill it as an enabling technology.
I would consider the needs of the mathematical community to be pretty
complex, so complex that tying the evolution of that datatype to HTML's
very rocky evolutionary path could be a big problem.
> > Separating it out makes implementation 10x
> >easier (just distribute plug-ins),
>
> How many plugins? One for every processor/OS combination?
I think the days of having to code plug-ins to specific platforms are
numbered, numbered by how well Java compilers shape up in efficiency.
Furthermore, using <object> to embed the mathematics, combined with
proper content negotiation, means that the author can provide high-level
and low-level representations of the math objects, such that if someone
is viewing the page with a browser only capable of rendering HTML and
GIF's, the server could give the user a GIF of the mathematical
equation. If it's a text-only browser, the author could generate (to
their liking/quality control) a text equivalent. Of course, with Lynx
2.5 claiming to "Accept:" a bunch of image formats this is something of a
problem.
> A big advantage
> of staying within html is to stay platform-independent.
Putting it in HTML doesn't automagically implement it in the worlds'
browsers. In fact, something as hairy and complex as math support could
prevent all but the most well-funded browser companies from being able to
support it (yes, I know it's in arena). If it's left as something for
<object> to embed, then browser authors don't even need to worry about
it. If we all could agree on a plug-in architecture then math support is
coded once and that's that.
> On the other hand, one could certainly imagine math markup interpreted by a
> general-purpose applet interpreter. Provided the interpreter is already
> widely available (e.g., Java) then the portability issue is addressed. And
> if the math markup is reasonably readable as text, browsers without
> interpreter support, or without graphics, might do ok to just present it
> uncooked.
Hmm... it would be interesting to see what that API would look like,
since rendering decisions take something of a holistic approach, no?
Can the rendering of a specific tag be chunked off to a plug-in? What if
I use other non-math HTML commands within the plug-in?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com | We're hiring! http://www.organic.com/Home/Info/Jobs/