<math>, <fig>, ... (fwd)

MegaZone (megazone@livingston.com)
Thu, 9 May 1996 18:04:43 -0700 (PDT)

Message-Id: <199605100104.SAA28314@server.livingston.com>
Subject: <math>, <fig>, ... (fwd)
To: www-html@w3.org
Date: Thu, 9 May 1996 18:04:43 -0700 (PDT)
From: MegaZone <megazone@livingston.com>

Once upon a time schwarte shaped the electrons to say...
>In HTML 3.2 some of the HTML 3.0 tags don=B4t occure. <MATH> and <FIG> and
>related elements have been skipped. WHY??

<MATH> is still muddled and <FIG> is dead.

You will most likely never see <FIG> implimented in any major browser.
<FIG> has been incorporated into <OBJECT> basically - much more flexible.

>But that is not a reason to destroy them.=20

They never existed officially!  It is BAD practice to assume just bacause
a tag is proposed that it will ever be ratified and official.  I can propose
tags all day (and have <INSERT>, but the <OBJECT> proposal firmed up and
it does most of what I was looking for) but that doesn't mean they will
ever exist or do what they first proposal stated.

>I think unimplemented and unused <math>-tags are better then
>no math tags at all. Too much has allready been written about this.

I hope you realize that any <MATH> documentation you have done to this
point is likely to be incorrect anyway by the time the final spec is done.

And you don't put tags into a spec when the tags have nothing to back them
up.  If someone wants to use <MATH> then they are not using the 3.2 DTD - 

>BTW, I am the author of a german book about HTML, that also has been
>published in frensh and dutch, and this books describes <math> and <fig>
>and all the related elements and so do most of the books I know. My

And that is bad practice on the part of the authors *unless* they make
is VERY VERY clear that the tags are *not* ratified, *unofficial*, and
*likely* to change or die.  Then an person doing pages can choose to use
them knowing they risk having to redo them later.

If an author misleads her readers into believing these phantom tags are
concrete - then I think we should flay the author alive with live multicast
on MBONE to serve as an example to others.

>There is hardly any HTML-author who is not aware of the existance of
>the mentioned HTML 3.0 tags and of their special syntax.

HTML 3.0 was never official, it was always just a lumped proposal - and
a lot of those tags are dead and buried, and many others a mutated.  Any
author who documented HTML 3.0 as if it was a final, solid draft was 
exceedingly foolish.

>Later contributions to HTML concerning Math. or Figures should be
>upwards compatible to the HTML 3.0 suggestions as far as possible.=20
>Will this happen?

Nope.  As I said <FIG> is dead and replaced - it was poor anyway (block
level tag?  I don't think so) and <MATH> is stumbling around in its
infancy still, very, very likely to mutate quite a bit as it grows and
matures - like any spec.

Welcome to the Internet.  If you document anything experimental (as ALL of
3.0 was) *expect* to have to rewrite your docs.

>Now back to the question -  WHY have those elements been eliminated?

Because they were *EXPERIMENTAL*.  They haven't been eliminated - they
never existed.  Think of experimental drafts as blueprints for a building.

If the building is later never build, do you claim the building was 
eliminated?  No, you don't.

That is what has happened here.  In some cases the building was never built.
In others they brought in a new team of architects and redesigned the whole
thing so the building that was built is nothing like the original plans.

>in the DTD. But don=B4t forget there are a few very interesting=
> noncommercial
>browsers too! UdiWWW, which is distributed on the CD that is part of my=20

So?  The people who wrote these browsers know very well that when they
added support for those tags they did so risking the chance that the tags
will never become official.  They got lucky in some cases and lost in
others - that's life.  If you choose to support an experimental tag when
writing a browser, that is your decision.  That doesn't mean for a second
that tag needs to remain as is or that the final version needs to be
backwards compatible with the experimental version - in some cases (<FIG>
IMHO) such things would be bad design.

Although I work for Livingston Enterprises Technical Support, I alone am
responsible for everything contained herein.  So don't waste my managers'
time bitching to them if you don't like something I've said.  Flame me.
Phone: 800-458-9966  support@livingston.com  <http://www.livingston.com/> 
FAX: 510-426-8951    6920 Koll Center Parkway #220, Pleasanton, CA 94566