2004/id/draft-seidman-clientsideimagemap-02.txt


INTERNET-DRAFT                                          James L. Seidman
<draft-ietf-html-clientsideimagemap-01.txt>             Spyglass, Inc.
Expires SIX MONTHS FROM--->                             December 1, 1995

      A Proposed Extension to HTML : Client-Side Image Maps

Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   To learn the current status of any Internet-Draft, please check
   the "1id-abstracts.txt" listing contained in the Internet-
   Drafts Shadow Directories on ds.internic.net (US East Coast),
   nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
   munnari.oz.au (Pacific Rim).

   Distribution of this document is unlimited.  Please send
   comments to the HTML working group (HTML-WG) of the
   Internet Engineering Task Force (IETF) at <html-wg@oclc.org>.
   Discussions of the group are archived at
   URL: http://www.acl.lanl.gov/HTML_WG/archives.html.

Abstract

   The markup language known as "HTML/2.0" provides for image maps.
   Image maps are document elements which allow clicking different
   areas of an image to reference different network resources, as
   specified by Uniform Identifier (URIs).  The image map
   capability in HTML/2.0 is limited in several ways, such as the
   restriction that it only works with documents served via the "HTTP"
   protocol, and the lack of a viable fallback for users of text-only
   browsers.  This document specifies an extension to the HTML
   language, referred to as "Client-Side Image Maps," which resolves
   these limitations.

Editor's Note:

All modifications to this internet-draft since the previous version are all
either editorial in nature or represent updates to reflect changes in other
referenced documents.  No significant changes have been made to the
specification itself.

   
Table of Contents

   1.  Introduction
       1.1  Purpose
       1.2  Overall Operation
   2.  Client-Side Image Map Extension
       2.1  Syntax
       2.2  Required Changes to HTML/2.0 DTD
       2.3  Backwards Compatibility
       2.4  Examples
   3.  Security Considerations
   4.  References
   5.  Author's Address


1. Introduction

1.1  Purpose

   Image maps are an important feature of the point-and-click
   interface which makes the World Wide Web so popular. The most
   common use of image maps is to allow users to access different
   documents by clicking different areas in an image.

   There are several limitations of the current image map
   implementation as it applies to this use. First, it only works
   over the HTTP protocol, making it unusable for reading local files
   or files accessed via alternate protocols. Second, a server
   transaction is required merely to determine where the link is
   directed. This can degrade performance noticeably when accessing
   distant sites. Third, unlike for normal links, there is no way for
   a browser to provide visual feedback to the user showing where a
   portion of an image map leads before the user actually clicks
   it. Lastly, the method for specifying the active regions of image
   maps is server-dependent, compromising portability of documents.
   This extension to support client-side image maps addresses these
   issues.

   It is proposed that this extension be included in a future revision
   of the HTML specification.

1.2  Overall Operation

   Client-side image maps work by placing a complete representation of
   the active areas of an image, including their shape, size, and
   destination (URI), into an SGML-compliant textual form.  This
   markup may also optionally include a textual description for
   each area for display on non-textual browsers.  This
   representation, or "map," is given a name to identify it.

   When an image is included in an HTML document, it may include an
   attribute specifying a map to use.  The map may be contained in the
   same file which references the image, but this it not required.
   If the map is in a different file, a URI to that file must be
   provided.

   The browser will parse the map and remember the contents.  When the
   user clicks the map, the browser will match up the location with
   the specified destination for that location and access that URI.
   In the case of a non-graphical browser, the browser could display
   the textual descriptions for each area instead of the image.
   Clicking a given textual description would then go to the
   associated destination. 


2. Client-Side Image Map Extension

2.1 Syntax
   
   Adding a USEMAP attribute to an IMG element indicates that it is a
   client-side image map.  The USEMAP attribute can be used with the
   ISMAP attribute to indicate that the image can be processed as
   either a client-side or server-side image map.  The argument to
   USEMAP specifies which map to use with the image, by specifying the
   URI for the file containing the map, followed by a '#', followed by
   the name of the map.  If the argument to USEMAP starts with a '#',
   the map is assumed to be in the same document as the IMG tag.  The
   presence of a USEMAP attribute overrides the effect of an enclosing
   anchor (A) element.
   
   The different regions of the image are described using a MAP
   element.  The map describes each region in the image and indicates
   where it links to. The basic format for the MAP element is as
   follows:

   <MAP NAME="name">
   <AREA [SHAPE="shape"] COORDS="x,y,..." [HREF="reference"]
         [NOHREF] [ALT="alt"]>
   </MAP>

   The NAME attribute specifies the name of the map so that it can be
   referenced by an IMG element.  Each AREA element contained inside
   the map element specifies a single clickable area of the image.
   The SHAPE attribute gives the shape of this area.  Possible shapes
   are "RECT", "CIRCLE", and "POLYGON", which specify rectangular,
   circular, and polygonal regions respectively.  If the SHAPE tag is
   omitted, SHAPE="RECT" is assumed.
   
   The COORDS tag describes the position of an area, using image
   pixels as the units with the origin at the upper-left corner of the
   image.  For a rectangle, the coordinates are given as
   "left,top,right,bottom".  The rectangular region defined includes
   the lower-right corner specified, i.e. to specify the entire area
   of a 100x100 image, the coordinates would be "0,0,99,99".
   
   For a circular region, the coordinates are given as
   "center_x,center_y,radius", specifying the center and radius of the
   circle.  All points up to and including those at a distance of
   "radius" points from the center are included.  For example, the
   coordinates "4,4,2" would specify a circle which included the
   coordinates (2,4) (6,4) (4,2) and (4,6).

   For a polygonal region, the coordinates specify successive
   vertices of the region in the format "x1,y1,x2,y2,...,xn,yn".
   If the first and last coordinates are not the same then a segment
   is inferred to close the polygon.  The region includes the
   boundary lines of the polygon.  For example, "20,20,30,40,10,40"
   would specify a triangle with vertices at (20,20) (30,40) and
   (10,40).  No explicit limit is placed on the number of vertices,
   but a practical limit is imposed by the fact that HTML limits
   an attribute value to 1024 characters.

   The NOHREF attribute indicates that clicks in this region should
   perform no action.  An HREF attribute specifies where a click in
   that area should lead.  A relative anchor specification will be
   expanded using the URI of the map description as a base, rather
   than using the URI of the document from which the map description
   is referenced. If a BASE tag is present in the document containing
   the map description, that URI will be used as the base.

   An arbitrary number of AREA tags may be specified.  If two areas
   intersect, the one which appears first in the map definition takes 
   precedence in the overlapping region.  Multiple areas may share the
   same destination to create composite shapes.  Any portion of an
   image which is not described by an AREA tag defaults to having no
   action.

   The ALT attribute specifies optional text which describes a given
   area.  A text-only browser can display the textual contents for
   each area as a substitute for the image.

2.2  Required Changes to HTML/2.0 DTD

   The required changes to the HTML/2.0 DTD to support this syntax
   would be as follows:

      Change the IMG element definition to be:
        <!ELEMENT IMG    - O EMPTY>
        <!ATTLIST IMG
                SRC CDATA #REQUIRED
                ALT CDATA #IMPLIED
                ALIGN (top|middle|bottom) #IMPLIED
                ISMAP (ISMAP) #IMPLIED
                USEMAP %URI; #IMPLIED
                %SDAPREF; "<Fig><?SDATrans Img: #AttList>#AttVal(Alt)</Fig>"
        >
           
      Add the following new definitions:
        <!ELEMENT MAP    - - +(AREA)>
        <!ATTLIST MAP
                NAME %linkName; #REQUIRED
        >

        <!ELEMENT AREA   - O EMPTY>
        <!ATTLIST AREA
                SHAPE (RECT|CIRCLE|POLYGON) RECT #IMPLIED
                COORDS CDATA #REQUIRED
                HREF %URI; #IMPLIED
                NOHREF (NOHREF) #IMPLIED
                ALT CDATA #IMPLIED
        >


2.3  Backwards Compatibility

   This extension is specifically designed to provide a variety of
   fallback options for browsers which do not support it.  These
   options are based on the assumption that browsers will ignore any
   attributes or elements which are not present in the HTML/2.0 DTD.

   An document can be written so that a client-side image map can have
   three different fallback behaviors.  First, the document can use
   the server-side image map capability, by specifying the ISMAP
   attribute as well as USEMAP.  In situations where this is possible,
   the image map will work whether or not the browser supports the
   client-side extension.

   Second, clicking the image can direct the user to a single URI,
   regardless of where on the image he clicks.  This is accomplished
   by placing the image inside an anchor (A) element.  The fallback
   destination could provide the user with an error or a textual list
   of destinations.
  
   Lastly, the image can appear to not be a link at all (i.e. missing
   whatever visual cues a browser provides to indicate a hyperlink).
   This will be the result if the image element neither contains an
   ISMAP attribute nor is inside an anchor.

2.4  Examples

   The following three examples show markup demonstrating the three
   fallback mechanisms described in section 2.3:

      This image map will work with any graphical browser:
      <A HREF="/cgi-bin/imagemap/pic1">
      <IMG SRC="pic1.jpg" USEMAP="maps.html#map1" ISMAP></A>

      Clicking here will take you to a page with an error message if
      you don't have client-side image map support:
      <A HREF="no_csim.html">
      <IMG SRC="pic2.jpg" USEMAP="maps.html#map2"></A>   

      You can only click here if your browser supports client-side
      image maps: <IMG SRC="pic3.jpg" USEMAP="maps.html#map3">

   The following example shows the use of a map in the same file as
   the image:

      <IMG SRC="picture.jpg" USEMAP="#mymap">

   The following example defines a simple map which describes an
   image with a circle in the middle overlapping two large
   rectangles:

      <MAP NAME="welcomemap">
      <AREA SHAPE=CIRCLE COORDS="50,50,40" HREF="about_us.html"
            ALT="About our company">
      <AREA SHAPE=RECT COORDS="0,0,100,50" HREF="products.html"
            ALT="Our products">
      <AREA SHAPE=RECT COORDS="0,51,100,100 HREF="technology.html"
            ALT="Technology for the next century">
      </MAP>

3. Security Considerations

   Clicking a portion of a client-side image map may cause a URI
   to be dereferenced.  In this case, the security considerations
   related to URLs [5] apply.

4. References

   [1] T. Berners-Lee, D. Connolly.  "HyperText Markup Language
       Specification - 2.0"  RFC 1866, November 1995.

   [2] J. Seidman, "An HTML Extension to Support Client-Side Image
       Maps"  The Second Internation WWW Conference '94 Advance
       Proceedings, pp 927-930.

   [3] "Standard Generalized Markup Language"  ISO Standard 8879:1986
       Information Processing Text and Office Systems.

   [4] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen,
       "Hypertext Transfer Protocol -- HTTP/1.0" Internet-Draft
       (work in progress), March 8, 1995.

   [5] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
       Resource Locators (URL)", RFC 1738, December 1994.
       
5. Author's Address

   James L. Seidman
   jim@spyglass.com
   Senior Software Engineer
   Spyglass, Inc.
   1230 East Diehl Road
   Naperville, IL 60563

1	wakaba	1.1
2			INTERNET-DRAFT James L. Seidman
3			<draft-ietf-html-clientsideimagemap-01.txt> Spyglass, Inc.
4			Expires SIX MONTHS FROM---> December 1, 1995
5
6			A Proposed Extension to HTML : Client-Side Image Maps
7
8			Status of this Memo
9
10			This document is an Internet-Draft. Internet-Drafts are working
11			documents of the Internet Engineering Task Force (IETF), its areas,
12			and its working groups. Note that other groups may also distribute
13			working documents as Internet-Drafts.
14
15			Internet-Drafts are draft documents valid for a maximum of six
16			months and may be updated, replaced, or obsoleted by other
17			documents at any time. It is inappropriate to use Internet-
18			Drafts as reference material or to cite them other than as
19			"work in progress."
20
21			To learn the current status of any Internet-Draft, please check
22			the "1id-abstracts.txt" listing contained in the Internet-
23			Drafts Shadow Directories on ds.internic.net (US East Coast),
24			nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
25			munnari.oz.au (Pacific Rim).
26
27			Distribution of this document is unlimited. Please send
28			comments to the HTML working group (HTML-WG) of the
29			Internet Engineering Task Force (IETF) at <html-wg@oclc.org>.
30			Discussions of the group are archived at
31			URL: http://www.acl.lanl.gov/HTML_WG/archives.html.
32
33			Abstract
34
35			The markup language known as "HTML/2.0" provides for image maps.
36			Image maps are document elements which allow clicking different
37			areas of an image to reference different network resources, as
38			specified by Uniform Identifier (URIs). The image map
39			capability in HTML/2.0 is limited in several ways, such as the
40			restriction that it only works with documents served via the "HTTP"
41			protocol, and the lack of a viable fallback for users of text-only
42			browsers. This document specifies an extension to the HTML
43			language, referred to as "Client-Side Image Maps," which resolves
44			these limitations.
45
46			Editor's Note:
47
48			All modifications to this internet-draft since the previous version are all
49			either editorial in nature or represent updates to reflect changes in other
50			referenced documents. No significant changes have been made to the
51			specification itself.
52
53
54			Table of Contents
55
56			1. Introduction
57			1.1 Purpose
58			1.2 Overall Operation
59			2. Client-Side Image Map Extension
60			2.1 Syntax
61			2.2 Required Changes to HTML/2.0 DTD
62			2.3 Backwards Compatibility
63			2.4 Examples
64			3. Security Considerations
65			4. References
66			5. Author's Address
67
68
69			1. Introduction
70
71			1.1 Purpose
72
73			Image maps are an important feature of the point-and-click
74			interface which makes the World Wide Web so popular. The most
75			common use of image maps is to allow users to access different
76			documents by clicking different areas in an image.
77
78			There are several limitations of the current image map
79			implementation as it applies to this use. First, it only works
80			over the HTTP protocol, making it unusable for reading local files
81			or files accessed via alternate protocols. Second, a server
82			transaction is required merely to determine where the link is
83			directed. This can degrade performance noticeably when accessing
84			distant sites. Third, unlike for normal links, there is no way for
85			a browser to provide visual feedback to the user showing where a
86			portion of an image map leads before the user actually clicks
87			it. Lastly, the method for specifying the active regions of image
88			maps is server-dependent, compromising portability of documents.
89			This extension to support client-side image maps addresses these
90			issues.
91
92			It is proposed that this extension be included in a future revision
93			of the HTML specification.
94
95			1.2 Overall Operation
96
97			Client-side image maps work by placing a complete representation of
98			the active areas of an image, including their shape, size, and
99			destination (URI), into an SGML-compliant textual form. This
100			markup may also optionally include a textual description for
101			each area for display on non-textual browsers. This
102			representation, or "map," is given a name to identify it.
103
104			When an image is included in an HTML document, it may include an
105			attribute specifying a map to use. The map may be contained in the
106			same file which references the image, but this it not required.
107			If the map is in a different file, a URI to that file must be
108			provided.
109
110			The browser will parse the map and remember the contents. When the
111			user clicks the map, the browser will match up the location with
112			the specified destination for that location and access that URI.
113			In the case of a non-graphical browser, the browser could display
114			the textual descriptions for each area instead of the image.
115			Clicking a given textual description would then go to the
116			associated destination.
117
118
119			2. Client-Side Image Map Extension
120
121			2.1 Syntax
122
123			Adding a USEMAP attribute to an IMG element indicates that it is a
124			client-side image map. The USEMAP attribute can be used with the
125			ISMAP attribute to indicate that the image can be processed as
126			either a client-side or server-side image map. The argument to
127			USEMAP specifies which map to use with the image, by specifying the
128			URI for the file containing the map, followed by a '#', followed by
129			the name of the map. If the argument to USEMAP starts with a '#',
130			the map is assumed to be in the same document as the IMG tag. The
131			presence of a USEMAP attribute overrides the effect of an enclosing
132			anchor (A) element.
133
134			The different regions of the image are described using a MAP
135			element. The map describes each region in the image and indicates
136			where it links to. The basic format for the MAP element is as
137			follows:
138
139			<MAP NAME="name">
140			<AREA [SHAPE="shape"] COORDS="x,y,..." [HREF="reference"]
141			[NOHREF] [ALT="alt"]>
142			</MAP>
143
144			The NAME attribute specifies the name of the map so that it can be
145			referenced by an IMG element. Each AREA element contained inside
146			the map element specifies a single clickable area of the image.
147			The SHAPE attribute gives the shape of this area. Possible shapes
148			are "RECT", "CIRCLE", and "POLYGON", which specify rectangular,
149			circular, and polygonal regions respectively. If the SHAPE tag is
150			omitted, SHAPE="RECT" is assumed.
151
152			The COORDS tag describes the position of an area, using image
153			pixels as the units with the origin at the upper-left corner of the
154			image. For a rectangle, the coordinates are given as
155			"left,top,right,bottom". The rectangular region defined includes
156			the lower-right corner specified, i.e. to specify the entire area
157			of a 100x100 image, the coordinates would be "0,0,99,99".
158
159			For a circular region, the coordinates are given as
160			"center_x,center_y,radius", specifying the center and radius of the
161			circle. All points up to and including those at a distance of
162			"radius" points from the center are included. For example, the
163			coordinates "4,4,2" would specify a circle which included the
164			coordinates (2,4) (6,4) (4,2) and (4,6).
165
166			For a polygonal region, the coordinates specify successive
167			vertices of the region in the format "x1,y1,x2,y2,...,xn,yn".
168			If the first and last coordinates are not the same then a segment
169			is inferred to close the polygon. The region includes the
170			boundary lines of the polygon. For example, "20,20,30,40,10,40"
171			would specify a triangle with vertices at (20,20) (30,40) and
172			(10,40). No explicit limit is placed on the number of vertices,
173			but a practical limit is imposed by the fact that HTML limits
174			an attribute value to 1024 characters.
175
176			The NOHREF attribute indicates that clicks in this region should
177			perform no action. An HREF attribute specifies where a click in
178			that area should lead. A relative anchor specification will be
179			expanded using the URI of the map description as a base, rather
180			than using the URI of the document from which the map description
181			is referenced. If a BASE tag is present in the document containing
182			the map description, that URI will be used as the base.
183
184			An arbitrary number of AREA tags may be specified. If two areas
185			intersect, the one which appears first in the map definition takes
186			precedence in the overlapping region. Multiple areas may share the
187			same destination to create composite shapes. Any portion of an
188			image which is not described by an AREA tag defaults to having no
189			action.
190
191			The ALT attribute specifies optional text which describes a given
192			area. A text-only browser can display the textual contents for
193			each area as a substitute for the image.
194
195			2.2 Required Changes to HTML/2.0 DTD
196
197			The required changes to the HTML/2.0 DTD to support this syntax
198			would be as follows:
199
200			Change the IMG element definition to be:
201			<!ELEMENT IMG - O EMPTY>
202			<!ATTLIST IMG
203			SRC CDATA #REQUIRED
204			ALT CDATA #IMPLIED
205			ALIGN (top\|middle\|bottom) #IMPLIED
206			ISMAP (ISMAP) #IMPLIED
207			USEMAP %URI; #IMPLIED
208			%SDAPREF; "<Fig><?SDATrans Img: #AttList>#AttVal(Alt)</Fig>"
209			>
210
211			Add the following new definitions:
212			<!ELEMENT MAP - - +(AREA)>
213			<!ATTLIST MAP
214			NAME %linkName; #REQUIRED
215			>
216
217			<!ELEMENT AREA - O EMPTY>
218			<!ATTLIST AREA
219			SHAPE (RECT\|CIRCLE\|POLYGON) RECT #IMPLIED
220			COORDS CDATA #REQUIRED
221			HREF %URI; #IMPLIED
222			NOHREF (NOHREF) #IMPLIED
223			ALT CDATA #IMPLIED
224			>
225
226
227			2.3 Backwards Compatibility
228
229			This extension is specifically designed to provide a variety of
230			fallback options for browsers which do not support it. These
231			options are based on the assumption that browsers will ignore any
232			attributes or elements which are not present in the HTML/2.0 DTD.
233
234			An document can be written so that a client-side image map can have
235			three different fallback behaviors. First, the document can use
236			the server-side image map capability, by specifying the ISMAP
237			attribute as well as USEMAP. In situations where this is possible,
238			the image map will work whether or not the browser supports the
239			client-side extension.
240
241			Second, clicking the image can direct the user to a single URI,
242			regardless of where on the image he clicks. This is accomplished
243			by placing the image inside an anchor (A) element. The fallback
244			destination could provide the user with an error or a textual list
245			of destinations.
246
247			Lastly, the image can appear to not be a link at all (i.e. missing
248			whatever visual cues a browser provides to indicate a hyperlink).
249			This will be the result if the image element neither contains an
250			ISMAP attribute nor is inside an anchor.
251
252			2.4 Examples
253
254			The following three examples show markup demonstrating the three
255			fallback mechanisms described in section 2.3:
256
257			This image map will work with any graphical browser:
258			<A HREF="/cgi-bin/imagemap/pic1">
259			<IMG SRC="pic1.jpg" USEMAP="maps.html#map1" ISMAP></A>
260
261			Clicking here will take you to a page with an error message if
262			you don't have client-side image map support:
263			<A HREF="no_csim.html">
264			<IMG SRC="pic2.jpg" USEMAP="maps.html#map2"></A>
265
266			You can only click here if your browser supports client-side
267			image maps: <IMG SRC="pic3.jpg" USEMAP="maps.html#map3">
268
269			The following example shows the use of a map in the same file as
270			the image:
271
272			<IMG SRC="picture.jpg" USEMAP="#mymap">
273
274			The following example defines a simple map which describes an
275			image with a circle in the middle overlapping two large
276			rectangles:
277
278			<MAP NAME="welcomemap">
279			<AREA SHAPE=CIRCLE COORDS="50,50,40" HREF="about_us.html"
280			ALT="About our company">
281			<AREA SHAPE=RECT COORDS="0,0,100,50" HREF="products.html"
282			ALT="Our products">
283			<AREA SHAPE=RECT COORDS="0,51,100,100 HREF="technology.html"
284			ALT="Technology for the next century">
285			</MAP>
286
287			3. Security Considerations
288
289			Clicking a portion of a client-side image map may cause a URI
290			to be dereferenced. In this case, the security considerations
291			related to URLs [5] apply.
292
293			4. References
294
295			[1] T. Berners-Lee, D. Connolly. "HyperText Markup Language
296			Specification - 2.0" RFC 1866, November 1995.
297
298			[2] J. Seidman, "An HTML Extension to Support Client-Side Image
299			Maps" The Second Internation WWW Conference '94 Advance
300			Proceedings, pp 927-930.
301
302			[3] "Standard Generalized Markup Language" ISO Standard 8879:1986
303			Information Processing Text and Office Systems.
304
305			[4] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen,
306			"Hypertext Transfer Protocol -- HTTP/1.0" Internet-Draft
307			(work in progress), March 8, 1995.
308
309			[5] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
310			Resource Locators (URL)", RFC 1738, December 1994.
311
312			5. Author's Address
313
314			James L. Seidman
315			jim@spyglass.com
316			Senior Software Engineer
317			Spyglass, Inc.
318			1230 East Diehl Road
319			Naperville, IL 60563
320