summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1980.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1980.txt')
-rw-r--r--doc/rfc/rfc1980.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc1980.txt b/doc/rfc/rfc1980.txt
new file mode 100644
index 0000000..76d2a9b
--- /dev/null
+++ b/doc/rfc/rfc1980.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group J. Seidman
+Request for Comments: 1980 Spyglass, Inc.
+Category: Informational August 1996
+
+
+ A Proposed Extension to HTML : Client-Side Image Maps
+
+Status 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 Contents
+
+ 1. Introduction ............................................... 1
+ 1.1 Purpose ............................................... 1
+ 1.2 Overall Operation ..................................... 2
+ 2. Client-Side Image Map Extension ............................ 2
+ 2.1 Syntax ................................................ 2
+ 2.2 Required Changes to HTML/2.0 DTD ...................... 4
+ 2.3 Backwards Compatibility ............................... 5
+ 2.4 Examples .............................................. 5
+ 3. Security Considerations .................................... 6
+ 4. References ................................................. 6
+ 5. Author's Address ........................................... 7
+
+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.
+
+
+
+
+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 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
+
+
+
+Seidman 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 expanded
+
+
+
+Seidman 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 1996
+
+
+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">
+
+
+
+
+
+
+
+
+
+
+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 1996
+
+
+5. Author's Address
+
+James L. Seidman
+Senior Software Engineer
+Spyglass, Inc.
+1230 East Diehl Road
+Naperville, IL 60563
+
+EMail: jim@spyglass.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Seidman Informational [Page 7]
+