Mosaic2.0 and ISINDEX (Marc Andreessen)
Date: Tue, 16 Nov 93 01:42:51 -0800
From: (Marc Andreessen)
Message-id: <>
To: Terry Allen <>,,
Subject: Mosaic2.0 and ISINDEX
In-reply-to: <>
References: <>
Actually, I don't think my response was sufficient.  Let's step
through this in more detail.

> Terry Allen writes:
> > Mosaic2.0's treatment of the ISINDEX tag is now in violation of the
> > HTML+ DTD.  

A DTD is, by definition, a document type definition, not a display
technology specification.

A display technology cannot be in violation of a DTD -- by definition,
only a document can be in violation of a DTD.

A display technology that does not properly handle all documents that
conform to a given DTD is broken with respect to that DTD and cannot
claim that it properly handles all documents that conform to that DTD.

Mosaic 2.0 properly handles documents that conform to the HTML DTD
(whatever it happens to be today, and with the caveat that this, as
usual, holds only until someone can provide us with a testcase to the
contrary) and also properly handles documents that include forms as
specified in the latest HTML+ DTD (which may not be out yet, but we've
been coordinating with the DTD author, so there should be no problems

> > According to the DTD, the tag is allowed only in HEAD---that is,
> > it's metainformation about the doc, 

OK so far -- but to be clear, let's nail down that "the tag is allowed
only in HEAD" applies to *documents* (which it, obviously, does).

> > and was thus properly implemented in the frame of 1.2.

Not accurate.  You are, in my opinion, attempting to force a given
display technology method to suit your particular preferences by
claiming a violation in our particular method of handling (presenting)
a part the document spec, which is by definition not reasonable due to
the separation of markup and presentation inherent in our approach.

> > Now Mosaic renders a search field in the document wherever the tag
> > appears: if it appears properly in HEAD, the search field is at the
> > top of the doc, 

The document conforms to the DTD, and Mosaic handles it properly.

> > but if it appears improperly elsewhere, the field is still
> > rendered.

The document does NOT conform to the DTD and Mosaic does as best it
can in the name of robustness.  The document should be fixed.

> > If browser developers won't stick to the DTD, there's no point in
> > having one.

Makes no sense.  We properly handle all documents that conform to the

Could be reworded quite reasonably as: "If document writers won't
stick to the DTD, there's no point in having one."


I think it's safe to say that the root problem here is that you are
unhappy with how Mosaic 2.0 handles ISINDEX.  There are several
previously-stated reasons why we now do what we do in 2.0...

 o Consistent approach to query mechanisms inside Mosaic. 
 o Allow code and interface complexity to be reduced. 
 o A few nasty problems were hitting the "popup text entry field"
   approach attempted for prerelease 2; notably, lots of unavoidable
   flashing when field popped up and down and intermittent but crippling
   Motif geometry management problem. This change removes those
 o Everyone wants the ability to enter a query (and the corresponding
   widgets) to be present only when the document is actually an ISINDEX
   document; this provides that very cleanly. 
 o This solves existing problem of when to retain contents of search field
   -- since search field now exists on a per-document basis, this is very
 o Encourage experimentation with fill-out forms by presenting an
   example for existing query engines. 

The primary problem that keeps me from simply putting in an option to
make you happy is the third one in the list above; after hours of
experimentation I couldn't get Motif to do what I wanted without
hitting intermittent bugs that ended up making the program unusable on
some systems.