- From: Nick Gibbins <gibbins@cpd.ntc.nokia.com>
- Date: Wed, 20 Sep 1995 12:19:47 +0100
- To: www-html@w3.org
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
Received on Wednesday, 20 September 1995 07:27:06 UTC