Re: Inline support for vector files (client-side imagemap)

Brandon Plewe (plewe@acsu.buffalo.edu)
Tue, 22 Nov 1994 16:45:26 -0500


At 09:09 PM 11/22/94 +0100, Chris Lilley, Computer Graphics Unit wrote:
>HTML 3 FIG elements define hotlinks and active regions in a standardised
way for
>all inline figures, to allow
>
>- client side processing
>- user feedback such as cursor changes or URLs shown as the user
> moves over an active area
>- automatic support for non-imaging clients (text prowsers, browsers for
> the print impaired)
>
>Provided the units can be ems as well as pixels, as is done with other
parts of
>the HTML 3 sketch DTD, then in conjunction with the width and height
attributes
>of the FIG element this support could be trivially extended to inline vector
>graphics, inline movies, etc doing all this in a consistent way.
>
>This would also allow a form-driven CGI script to generate HTML as required
with
>different hot areas on the same CGM (which, being in the browser cache, will
>greatly speed up responsiveness to the user).
>

I have been very leery of the Client-side imagemaps, and the prospect of vector
images makes me moreso. One problem with the client-side approach is that it
is not very scalable. I run several imagemaps now with over 50 hotspots, and
those of us in the GIS/Mapping industry have several applications waiting in
the wings which could conceivably have thousands of hotspots. I don't think
anyone would want these encoded in the HTML code. In my mind, the best place
to encode these is within the file itself (I say that because I would probably
be generating the files on-the-fly, not using existing CGM files).

The other problem denotes that you seem to have missed one of the advantages
of Softsource's proposal (which could just as easily be done with CGM), which
is the ability of the browser/viewer to do zooming and panning on the file.
How would moving targets be handled with client-side imagemap definitions?

The first two of your three points above can be done with graphics-file-
encoded imagemaps just as easily as client-side. I believe all three imagemap
methods have their merits for different situations, and would like to see them
all stick around.

About the standardization of CGM: I don't think it is any more difficult to
have a working group build a standard WWW CGM profile than to build SVF.

Vision: Vector support can impact much more than distributing engineering
drawings. If it is done right, it can lend a whole new metaphor to
the WWW. Designers could use either (preferably both, for graphics-impaired
users) a text-based metaphor (HTML) or a truly visual-based one (SVF/CGM),
both with the same hypertext capabilities. The two metaphors should be
compatible, but separable (i.e. I should have a graphics-based browser which
can include HTML text as part of an image, as well as vice versa).

Brandon Plewe
plewe@acsu.buffalo.edu