HTML 3.0 imagemaps vs NHTML imagemaps

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


From: Nick Gibbins <gibbins@cpd.ntc.nokia.com>
Date: Wed, 20 Sep 1995 12:19:47 +0100
Message-Id: <199509201119.MAA12945@crobin.uk.ntc.nokia.com>
To: www-html@w3.org
Subject: HTML 3.0 imagemaps vs NHTML imagemaps


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