Movatterモバイル変換

Network Working Group                                         J. SeidmanRequest for Comments: 1980                                Spyglass, Inc.Category: Informational                                      August 1996A Proposed Extension to HTML : Client-Side Image MapsStatus of this Memo   This memo provides information for the Internet community.  This memo   does not specify an Internet standard of any kind.  Distribution of   this memo is unlimited.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.Table of Contents1.  Introduction ...............................................11.1  Purpose ...............................................11.2  Overall Operation .....................................22.  Client-Side Image Map Extension ............................22.1  Syntax ................................................22.2  Required Changes to HTML/2.0 DTD ......................42.3  Backwards Compatibility ...............................52.4  Examples ..............................................53.  Security Considerations ....................................64.  References .................................................65.  Author's Address ...........................................71. Introduction1.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.Seidman                      Informational                      [Page 1]

RFC 1980                 Client-Side Image Maps              August 1996   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 Extension2.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 nameSeidman                      Informational                      [Page 2]

RFC 1980                 Client-Side Image Maps              August 1996   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   ircle.  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 expandedSeidman                      Informational                      [Page 3]

RFC 1980                 Client-Side Image Maps              August 1996   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    >Seidman                      Informational                      [Page 4]

RFC 1980                 Client-Side Image Maps              August 19962.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 insection 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">Seidman                      Informational                      [Page 5]

RFC 1980                 Client-Side Image Maps              August 1996   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] Berners-Lee, T., and D. Connolly, "HyperText Markup Language       Specification - 2.0",RFC 1866, November 1995.   [2] Seidman, J., "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] Berners-Lee, T., Fielding, R., and H. Frystyk Nielsen,       "Hypertext Transfer Protocol -- HTTP/1.0", Work in       Progress.   [5] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform       Resource Locators (URL)",RFC 1738, December 1994.Seidman                      Informational                      [Page 6]

RFC 1980                 Client-Side Image Maps              August 19965. Author's AddressJames L. SeidmanSenior Software EngineerSpyglass, Inc.1230 East Diehl RoadNaperville, IL 60563EMail: jim@spyglass.comSeidman                      Informational                      [Page 7]