Re: Toward Closure on HTML

Paul Burchard <burchard@horizon.gw.umn.edu>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 5 Apr 1994 20:21:35 --100
Message-id: <9404051817.AA02860@horizon.gw.umn.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: burchard@horizon.gw.umn.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Paul Burchard <burchard@horizon.gw.umn.edu>
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: 3106

Daniel W. Connolly writes:
>
> 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 


OK, thanks for clarifying that!

By the way I wholeheartedly agree that some sort of multipart  
capability is sorely needed, especially to speed up interaction with  
forms that contain dynamic images.  But this is a wishlist issue, and  
should be deferred to HTML+. 


> [...on the topic of forms...]
> I guess I just haven't worked with them enough to know
> _exactly_ how expressive they are. 


Well, once you have "text" and "image" inputs, you can do almost  
anything.  (For examples of essentially arbitrary widgets built on  
top of the "image" input, take a look at our interactive gallery,  
"http://www.geom.umn.edu/apps/gallery.html".)

The two main limitations of "image" inputs are: (1) only a single  
point of user input can be captured, and (2) lack of multipart  
capability adds a network delay penalties, limiting the number you  
can use practically.  The first problem is already being addressed  
very nicely in HTML+ by Dave Raggett's "scribble" input.

Actually, the biggest issue in forms is not expressiveness -- since  
the ACTION script can effectively supply it once "text" and  
"scribble" widgets are available -- but client/server balancing of  
that expressive power.  Right now the client side, although a lot  
smarter than an X display, is still pretty dumb.  Fortunately, Dave  
Raggett is working on (still secret!) scripting capabilities for  
HTML+ forms to address this problem.

Dave Raggett writes:
>
> A major reason for keeping forms and html together is the
> way html elements are used to layout forms. You can use
> most things including PRE to layout the fields and
> surrounding text and images. This makes it kind of tricky
> to say the least to separate them. Besides there is now a
> lot of experience with fill-out forms and this is being
> fed into further developments. Going back to ground zero
> would be a retrograde step. 


Exactly.  It's really important to be able to use arbitrary HTML  
inside a form -- forms just add interactive capabilities to HTML that  
have long been associated with hypermedia.

Although I think there is technical merit in Dan's suggestion to make  
"formness" an attribute of the whole document -- because multiple  
forms don't work anyway if you're trying to maintain state through  
hidden fields -- I don't see that we should be replacing features  
with less capable ones just to "protect the user".

Forms are out there, and already in their current state (X Mosaic  
2.2) provide some pretty powerful capabilities.  I say let's clamp  
that down into a base-level standard, so that experimentation into  
extensions (which is already happening) can have a solid foundation  
to build on.

--------------------------------------------------------------------
Paul Burchard	<burchard@geom.umn.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------