Re: Toward Closure on HTML

Marc Andreessen (marca@eit.COM)
Tue, 5 Apr 1994 17:09:24 GMT

"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.