HTML 3.0 imagemaps vs NHTML imagemaps

Nick Gibbins (gibbins@cpd.ntc.nokia.com)
Wed, 20 Sep 1995 12:19:47 +0100


While I do agree with Joe English's views[1] on NCOM's proposed FRAME
element (ie. that we should at least consider them), I was rather
dismayed by their proposed implementation of client side imagemaps.[2]

Rather than using the FIG-based imagemap from the HTML3.0 draft
specification[3], they are basing their implementation on Spyglass'
extension[4] using the MAP element. I believe that this is a backward
step, since it encourages the continued use of the IMG element, and
has no provision for backwards compatibility with those clients which
do not understand MAP, AREA, etc.

To quote from Spyglass' document[4]:

" While HTML+ contains provisions for "hypertext buttons" on images
via use of the FIG element, this method is an unworkable short-term
solution for several reasons. First, complete support of the FIG
element requires significant additional processing by the
browser. Second, it cannot degrade gracefully on browsers that do
not support it. Third, it requires the map description to be
specified when the image appears, which is inappropriate for some
applications. "

I believe that the first two points here raised are either irrelevant
or incorrect:

o support of FIG (with the possible exception of scaling) should
require no greater processing than should support of Spyglass'
imagemaps.

o FIG degrades more gracefully with non-graphical clients than does
Spyglass' proposal. Also, those graphical clients which do not
accept FIG can still present the links within the imagemap; the
same is not true of MAP.

I'm not completely sure that I understand the reasoning behind the
third point, but the document does have a good example of a situation
in which it would be useful to have an imagemap description which
could reside in a different document to the one which contains the
image:

" A common use of image maps is a button bar which appears at the
bottom of every document. The map description could be specified in
one file, such as the server's home page, and referenced from each
document. Thus, the map could be modified by changing a single map
description rather than having to modify every file on the
server. "

Unfortunately, this doesn't seem to be implementable without
compromising backwards compatibility.

I could find no reference in NCOM's release notes for Netscape 2.0 to
support of figures, or of true HTML3.0 tables.

My (rather irreverent) question is this: what role does the HTML WG
play, when the features they propose are actively ignored by the major
companies in favour of similar but inferior features?

--
Nick Gibbins                                       gibbins@cpd.ntc.nokia.com

[1] http://www.eit.com/www.lists/www-html.1995q3/0600.html [2] http://home.mcom.com/eng/mozilla/2.0/relnotes/ [3] http://www.w3.org/hypertext/WWW/MarkUp/html3/figures.html [4] http://www.spyglass.com/six/developers_tech_doc4.html