Re: Toward Closure on HTML

• Mail folder: WWW Talk Apr 94-present
• Next message: Jay C. Weber: "Re: Toward Closure on HTML"
• Previous message: Jim Davis: "Re: Toward Closure on HTML"
• Maybe in reply to: Stan Letovsky: "Re: Toward Closure on HTML "
• Reply: Marc Andreessen: "Re: Toward Closure on HTML "

Errors-To: listmaster@www0.cern.ch
Date: Tue, 5 Apr 1994 19:17:19 --100
Message-id: <199404051709.RAA04550@threejane>
Errors-To: listmaster@www0.cern.ch
Reply-To: marca@eit.COM
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: marca@eit.COM (Marc Andreessen)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Toward Closure on HTML 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2623

"Daniel W. Connolly" writes:
> In message <9404050317.AA06756@mobius.geom.umn.edu>, burchard@geom.umn.edu writ
> es:
> >Daniel W. Connolly writes:
> >>
> >> FORMS, TABLES, AND MATH
> >>
> >> 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.

Cheers,
Marc