link areas within images

• Mail folder: WWW Talk Apr-Jun 1993 Archives
• Next message: Marc Andreessen: "from Dr. SGML^H^H^H^H Macro..."
• Previous message: Kevin Altis: "Re: HTML+ support for eqn & Postscript"

Message-id: <9306182254.AA14423@rs042.scic.intel.com>
Date: Fri, 18 Jun 1993 15:53:33 -0800
To: www-talk@nxoc01.cern.ch
From: kevin@scic.intel.com (Kevin Altis)
X-Sender: kevin@rs042.scic.intel.com
Subject: link areas within images

Not all clients can display images, but images whether PostScript, GIF,
TeX, etc. will end up being part of many online documents. With that in
mind, I think that we need to be able to specify link areas within image
boundaries, not just the image itself as a link. For example, if you
provide a map image, a browser should support selecting particular
locations within that map image. The simplest way to do this is to specify
a rectangular boundary relative to one corner of the image. Since the image
may be scaled to fit within a browser window, the rectangular link area
would also have to be scaled.

PROPOSAL
I propose using the top left corner of the image as 0,0 (top,left) and
specifying the rectangular areas within the image as top,left,bottom,right
relative to the top left corner of the image, which fits with many of the
existing image models. top,left,bottom,right will be specified as positive
integers (you can't have a link area off the image). If a link area
overlaps another, then the first link area specified in the HTML for the
document would take precedence. Link areas within images should have
several highlighting types, much like Bold, Italics, and Underline for
text, so that link areas on the image can appear transparent to the user (a
rectangular highlight would distract from the rest of the image), some
highlight such as color or brightness change, or have a state showing the
link has been visited. Supporting arbitrary closed polygons as link areas
would require a little more work, but would be a good idea in the long run.

BENEFITS
Besides opening up a large number hypertext applications not currently
possible with HTML because the granularity of image links isn't precise
enough, supporting image links probably avoids some other complexities
threatening HTML. The discussions revolving around PRE and equations
indicate that HTML doesn't provide enough control to produce the kinds of
documents we're used to doing with TeX, FrameMaker, PostScript, etc.
However, those documents, or individual parts of those documents can be
rendered by other applications and returned as images to WWW browsers as
long as areas within those returned images still work as hypertext links. A
rendering application that returns an image, could also return relative
rectangles as valid HTML that would specify the location of a particular
word, phrase, embedded equation, embedded image, etc. dynamically, which
the browser can then add to the HTML for that document while the document
is being viewed.

Kevin Altis
Intel Corporation
SuperComputer Systems Division
Beaverton, Oregon