Re: Keeping HTML Simple & Format negotiation between Browser & Server
Tim Berners-Lee <timbl@www3.cern.ch>
Date: Tue, 1 Jun 93 13:14:39 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-id: <9306011214.AA00732@www3.cern.ch>
To: wei@xcf.berkeley.edu (Pei Y. Wei)
Subject: Re: Keeping HTML Simple & Format negotiation between Browser & Server
Cc: hoesel@chem.rug.nl, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch
On ISMAP vs Figure Anchors.
==========================
I agree that bot the ISMAP technique of returning coordinates to a
server, and the FIGA (HMML) technique of overlaying anchors on
pictures have uses. I feel that in fact their application areas
are quite separate.
It would be infuriating to have a ISMAP server which had some
areas selectable and others not, where you got back an error
message if you clicked in the wrong place. But on the other hand,
a good cyberspace web will have nodes on which you can click anywhere
to change your point of view.
So let's specify both. Now for protocols.
PLEASE KEEP OTHER INFO OUT OF LINKS
The ISMAP attribute has the problem that
it includes information in the link which ought to be
sent from the server when the map is retrieved. I would
suggest a methodname "SPACEJUMP" say in the Allowed: return
field. This allows the server to tag things as spacejumpable
however you ahve got to them. If for example you convert
a URN ionto a URL and retrieve the document, then you get
a spacejumpable version. If you have a graphics machine.
Some documents may become spacejumpable. Having to put information
like that in the links is bad because
1. It is duplication of information which implies
incorrect information.
2. It may change with time.
3. It may be a function of client and server
capabilities.
The same applied to the "type=immage/gif" which has been
suggested and Pei mentioned. PLEASE DON"T put type information
into the link! PLEASE use the full protcocol, using the libwww
or otherwise.
Scale coordinates please
I would point out too that we can forsee smart servers which will
for example, as a function of the client, automatically generate or
select
a 800*600 GIF to send instead of a 1200*1000 JPEG. This will make
transfers onto low-res and/or low-bandwidth clients much faster.
It will be completely automatic. It means that ISMAP coordinates
should be scaled to say 0 - 1.0 in the size of the picture,
as pixels won't have much meaning. Same applies of course anyway
to postscript pictures which have no concept of pixel size.
There's my 2c for today.
Tim