Re: Toward Closure on HTML

Paul Burchard (
Tue, 5 Apr 94 13:17:54 -0500

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,

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 <>
``I'm still learning how to count backwards from infinity...''