RFC 1980

A Proposed Extension to HTML : Client-Side Image Maps

๐Ÿ“… published August 1996, from ietf

RFC 1980: A Proposed Extension to HTML : Client-Side Image Maps ๐Ÿฆ‹

Okay bestie, let's get the basics out of the way first ๐Ÿ’… This one is RFC 1980, from the Network Working Group. It was written by J. Seidman at Spyglass, Inc. ๐ŸŒธ It's filed as Informational and dated August 1996. The header doesn't have an Obsoletes or Updates line, so it isn't listed as obsoleting or updating anything ๐Ÿงš

Status of this Memo โœจ

This memo is here to give information to the Internet community ๐Ÿ’œ It does not specify an Internet standard of any kind, so this isn't a standard, sorry ๐Ÿ™ˆ Distribution is unlimited, so you can share it as much as you want ๐Ÿซถ

Abstract ๐ŸŒˆ

Okay so image maps are the thing where you click different spots on a picture and get sent to different resources, which are identified by Uniform Identifier (URIs) ๐Ÿ–ฑ๏ธ HTML/2.0 has image maps, but they're kinda limited. They only work over the HTTP protocol, and there's no real fallback for text-only browsers ๐Ÿ˜ญ This document specifies an extension to the HTML language called "Client-Side Image Maps" that fixes all of that ๐Ÿ”ฅ

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 a big deal for the point-and-click vibe that made the World Wide Web so popular โœจ The most common use is letting people open different documents by clicking different areas of one image.

Current image maps have some limitations for this, and they're kinda annoying ๐Ÿ™„ First, they only work over the HTTP protocol, so you can't use them for local files or for files reached through other protocols. Second, the browser needs a server transaction just to figure out where the link goes, which can seriously slow things down when you're hitting a faraway site ๐Ÿข Third, unlike normal links, the browser can't show you where part of an image map leads before you click it. Lastly, how you specify the active regions depends on the server, which means your documents aren't very portable ๐Ÿ’€

Client-side image maps fix all of these issues ๐Ÿฆ‹

It is proposed that this extension be included in a future revision of the HTML specification ๐ŸŒธ

1.2 Overall Operation ๐Ÿซถ

So here's how client-side image maps work. The whole map, meaning the active areas of an image along with their shape, size, and destination (URI), gets packed into an SGML-compliant textual form ๐Ÿ“ฆ The markup can also optionally include a textual description for each area, which is great for non-textual browsers ๐Ÿ™Œ The map gets a name so it can be identified.

When an image shows up in an HTML document, it can include an attribute that says which map to use. The map can live in the same file as the image, but this is not required. If the map is in a different file, you have to provide a URI pointing to that file.

The browser parses the map and remembers what's in it. When the user clicks the image, the browser matches the click location to its destination and goes to that URI ๐ŸŽฏ For a non-graphical browser, it can show the textual descriptions for each area instead of the image, and clicking a description takes you to the matching destination ๐Ÿ’œ


2. Client-Side Image Map Extension ๐Ÿงš

2.1 Syntax ๐Ÿ’…

Adding a USEMAP attribute to an IMG element marks it as a client-side image map ๐Ÿ–ผ๏ธ You can use USEMAP together with ISMAP so the image can be processed as either a client-side or a server-side image map โœจ The argument to USEMAP says which map to use. You give the URI of the file that contains the map, then a #, then the name of the map. If the argument starts with a #, the map is assumed to be in the same document as the IMG tag. Having a USEMAP attribute overrides any enclosing anchor (A) element, so that anchor is basically ignored ๐Ÿ™ƒ

The different regions of the image are described with a MAP element ๐Ÿ—บ๏ธ The map describes each region and says where it links. The basic format for the MAP element looks like this:

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

The NAME attribute gives the map a name so an IMG element can reference it ๐Ÿท๏ธ Each AREA element inside the map describes one clickable area of the image. The SHAPE attribute sets the shape of that area. The options are "RECT", "CIRCLE", and "POLYGON", which mean rectangular, circular, and polygonal regions. If you leave out SHAPE, SHAPE="RECT" is assumed ๐Ÿ“

The COORDS attribute describes where an area is, using image pixels as units with the origin at the upper-left corner of the image ๐Ÿ“ For a rectangle, the coordinates go "left,top,right,bottom". The rectangle includes the lower-right corner you specify. So if you want the entire area of a 100x100 image, you'd use "0,0,99,99" ๐Ÿงฎ

For a circle, the coordinates are "center_x,center_y,radius", which gives the center and radius of the circle โญ• Every point up to and including those at a distance of radius pixels from the center is included. For example, "4,4,2" describes a circle that includes the coordinates (2,4), (6,4), (4,2), and (4,6) ๐ŸŒˆ

For a polygon, the coordinates list the successive vertices of the region in the format "x1,y1,x2,y2,...,xn,yn" ๐Ÿ”บ If the first and last coordinates aren't the same, a segment is inferred to close the polygon. The region includes the polygon's boundary lines. For example, "20,20,30,40,10,40" makes a triangle with vertices at (20,20), (30,40), and (10,40). There's no explicit limit on the number of vertices, but there is a practical one, because HTML limits an attribute value to 1024 characters ๐Ÿ˜ค

The NOHREF attribute means clicks in that region do nothing ๐Ÿšซ The HREF attribute says where a click in that area should lead. A relative anchor gets expanded using the URI of the map description as its base, not the URI of the document that references the map description ๐Ÿงญ If a BASE tag is present in the document containing the map description, that URI is used as the base instead.

You can specify any number of AREA tags. If two areas overlap, the one that appears first in the map definition wins in the overlapping region ๐Ÿฅ‡ Multiple areas can share the same destination to build composite shapes ๐Ÿงฉ Any part of the image that isn't described by an AREA tag has no action by default.

The ALT attribute holds optional text describing an area ๐Ÿ“ A text-only browser can show that text 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 that 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
>

Part 2 is where the fallback options live, so stay tuned ๐Ÿ‘€๐Ÿฆ‹

4. References โœจ

okay bestie, here are the receipts ๐Ÿงพ every source this spec leans on is listed below ๐Ÿ’…

[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.

5. Author's Address ๐Ÿ’–

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

EMail: jim@spyglass.com

๐Ÿ“ฆ where this page comes from