Re: Toward Closure? application/html-form

• Mail folder: WWW Talk Apr 94-present
• Next message: Jay C. Weber: "Re: Toward Closure on HTML"
• Previous message: Marc Andreessen: "Re: Toward Closure on HTML"

Errors-To: listmaster@www0.cern.ch
Date: Wed, 6 Apr 1994 00:48:04 --100
Message-id: <9404052243.AA29548@void.ncsa.uiuc.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: atotic@ncsa.uiuc.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: atotic@ncsa.uiuc.edu (Alexsander Totic)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Toward Closure? application/html-form
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2681      
Content-Length: 2681      
Content-Type: text/plain; charset=US-ASCII
Content-Type: text/plain; charset=US-ASCII
Mime-Version: 1.0
Mime-Version: 1.0
X-Mailer: ELM [version 2.4 PL23]
X-Mailer: ELM [version 2.4 PL23]

> I don't think so. I've seen lots of pages that say "You'll need a WWW
> client that understands forms to use this..." I think current practice
> most certainly does include the notion of labelling forms-using pages
> as such.

The problem is the general problem of what an HTML browser should do if
it encounters an unrecognizable HTML tag. For example, if MacMosaic has put
in a warning 
"This document uses forms, a feature not currently supported by MacMosaic"

on top of every page that included <FORM>, I bet that you would see very
few build-in warnings. The same problem existed briefly with ISMAP feature
too. Instead of arguing about what should be part of HTML, it would be better
if there was a suggested mechanism about what a browser that does not
support a particular feature should do when it is encountered. Somewhat of a
Precedent is the <IMG> tag in lynx.

If application/html-form is defined, it would set a dangerous precedent of
trying to classify each major new feature into a separate document type.
A few years from now, a browser would be sending a request:

ACCEPT application/html-form
ACCEPT application/html-form-figure
ACCEPT application/html-figure
ACCEPT application/html-tables
ACCEPT application/html-form-custom-widget
ACCEPT application/html-form-custom-widget-live-socket-playback

If necessary, we can add an extra field to the HTTP request, that 
indicates how HTML savvy application is. This would also create a natural
compatibility hierarchy.

> I misspoke on inlined images. There's nothing wrong with the IMG
> element. But I think we need a way to combine image/gif data and
> text/html data into one transaction. But that technique is not
> ready for standardization yet. That's what I meant.

For those wishing to include images into multipart mime format, you will have
to define a system so that user's preferences are transmitted back to the
server, because many users do not want inline images because of the bandwidth.

A few thoughts on how will new MacMosaic handle the dreaded <P> tag:
Because it is impossible to make <P> a proper container in all the broken
documents out there, I have decided to treat <P> and </P> the same. They
both indicate a wish for whitespace. The difference between <P> and <BR> is
that <P> gives you more space, and multiple <P> are collapsed into 1. Also,
care is taken so that other surrounding tags such as <H*> do not conspire to
create vast regions of white space.

Since URL specs are at their final draft right now, I have hope that HTML will
eventually move in the same direction. The longer we wait, the harder it will
be to reconcile all the slightly different implementations.

Aleks