Re: Toward Closure on HTML

marca@eit.COM (Marc Andreessen)
Date: Tue, 5 Apr 1994 19:17:19 --100
Message-id: <199404051709.RAA04550@threejane>
Reply-To: marca@eit.COM
Precedence: bulk
From: marca@eit.COM (Marc Andreessen)
To: Multiple recipients of list <>
Subject: Re: Toward Closure on HTML 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2623
"Daniel W. Connolly" writes:
> In message <>, writ
> es:
> >Daniel W. Connolly writes:
> >>
> >>
> >> I think forms should be a separate document type.  I don't
> >> see a requirement to be able to include forms inside
> >> arbitrary documents. And I see more value in separating
> >> them from the normal HTML document type.
> >>
> >> The same goes for tables, math, and small inline images.
> >
> >Doesn't that largely defeat the purpose of this intermediate  
> >standardization effort, if you ignore key Mosaic features like inline  
> >images and interactive forms?
> I didn't mean to leave out the <IMG> tag -- I meant that we shouldn't
> standardize on a way to stick GIFs in the _same_datastream_ as
> HTML, somethin like:
> 	<inline-img>23l4i23o487234oiu23o4ijo23i4j</inline-img>
> The <img> element will certainly stay in the std.

Oh, OK, sorry -- sounds great.

> I'm not quite sure what to do with forms. But what I'm suggesting
> is that normal text/html _not_ include forms -- we make a separate
> type application/html-form or some such and another DTD that includes
> the form elements (plus most of the normal HTML elements).
> Forms don't fit several requrements that I had in mind:
> 	* One should be able to write an HTML->RTF converter. What
> 	happens to forms there?
> 	* What happens when forms get printed?
> But I don't mean to be adamant about anything. If there's a clear
> consensus on how forms work, I'm all for it, I guess.
> I guess I just haven't worked with them enough to know _exactly_ how
> expressive they are.

The point I was making in my somewhat abrupt earlier messages is that
it has in fact turned out that people have found a multitude of uses
for forms inside ordinary documents, and being able to provide that
functionality was a big step forward.  I can provide example URLs if
it would be helpful.

There are basically three languages we can define:

(a) HTML "pure"; no forms.
(b) HTML "pure" + forms; I call this "current practice", and this is
    what I'm encouraging should be frozen long enough to be shipped
    out as an informational RFC.
(c) HTML+.

I think (b) is the most important to lock down at this point in the
project, because it documents and semi-standardizes something that has
achieved widespread use (there are somewhere around 1,000,000 users of
browsers that support or almost support (b) at this point in time).
It is, I think, an important and logical plateau for us to establish
on our climb into the future, for that reason.