idnits 2.17.1 draft-seidman-clientsideimagemap-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-html-clientsideimagemap-01', but the file name used is 'draft-seidman-clientsideimagemap-02' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 320 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (December 1, 1995) is 10364 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'NOHREF' on line 137 == Unused Reference: '1' is defined on line 290, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 293, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 297, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 300, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1866 (ref. '1') (Obsoleted by RFC 2854) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1738 (ref. '5') (Obsoleted by RFC 4248, RFC 4266) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT James L. Seidman 2 Spyglass, Inc. 3 Expires SIX MONTHS FROM---> December 1, 1995 5 A Proposed Extension to HTML : Client-Side Image Maps 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet- 17 Drafts as reference material or to cite them other than as 18 "work in progress." 20 To learn the current status of any Internet-Draft, please check 21 the "1id-abstracts.txt" listing contained in the Internet- 22 Drafts Shadow Directories on ds.internic.net (US East Coast), 23 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 24 munnari.oz.au (Pacific Rim). 26 Distribution of this document is unlimited. Please send 27 comments to the HTML working group (HTML-WG) of the 28 Internet Engineering Task Force (IETF) at . 29 Discussions of the group are archived at 30 URL: http://www.acl.lanl.gov/HTML_WG/archives.html. 32 Abstract 34 The markup language known as "HTML/2.0" provides for image maps. 35 Image maps are document elements which allow clicking different 36 areas of an image to reference different network resources, as 37 specified by Uniform Identifier (URIs). The image map 38 capability in HTML/2.0 is limited in several ways, such as the 39 restriction that it only works with documents served via the "HTTP" 40 protocol, and the lack of a viable fallback for users of text-only 41 browsers. This document specifies an extension to the HTML 42 language, referred to as "Client-Side Image Maps," which resolves 43 these limitations. 45 Editor's Note: 47 All modifications to this internet-draft since the previous version are all 48 either editorial in nature or represent updates to reflect changes in other 49 referenced documents. No significant changes have been made to the 50 specification itself. 52 Table of Contents 54 1. Introduction 55 1.1 Purpose 56 1.2 Overall Operation 57 2. Client-Side Image Map Extension 58 2.1 Syntax 59 2.2 Required Changes to HTML/2.0 DTD 60 2.3 Backwards Compatibility 61 2.4 Examples 62 3. Security Considerations 63 4. References 64 5. Author's Address 66 1. Introduction 68 1.1 Purpose 70 Image maps are an important feature of the point-and-click 71 interface which makes the World Wide Web so popular. The most 72 common use of image maps is to allow users to access different 73 documents by clicking different areas in an image. 75 There are several limitations of the current image map 76 implementation as it applies to this use. First, it only works 77 over the HTTP protocol, making it unusable for reading local files 78 or files accessed via alternate protocols. Second, a server 79 transaction is required merely to determine where the link is 80 directed. This can degrade performance noticeably when accessing 81 distant sites. Third, unlike for normal links, there is no way for 82 a browser to provide visual feedback to the user showing where a 83 portion of an image map leads before the user actually clicks 84 it. Lastly, the method for specifying the active regions of image 85 maps is server-dependent, compromising portability of documents. 86 This extension to support client-side image maps addresses these 87 issues. 89 It is proposed that this extension be included in a future revision 90 of the HTML specification. 92 1.2 Overall Operation 94 Client-side image maps work by placing a complete representation of 95 the active areas of an image, including their shape, size, and 96 destination (URI), into an SGML-compliant textual form. This 97 markup may also optionally include a textual description for 98 each area for display on non-textual browsers. This 99 representation, or "map," is given a name to identify it. 101 When an image is included in an HTML document, it may include an 102 attribute specifying a map to use. The map may be contained in the 103 same file which references the image, but this it not required. 104 If the map is in a different file, a URI to that file must be 105 provided. 107 The browser will parse the map and remember the contents. When the 108 user clicks the map, the browser will match up the location with 109 the specified destination for that location and access that URI. 110 In the case of a non-graphical browser, the browser could display 111 the textual descriptions for each area instead of the image. 112 Clicking a given textual description would then go to the 113 associated destination. 115 2. Client-Side Image Map Extension 117 2.1 Syntax 119 Adding a USEMAP attribute to an IMG element indicates that it is a 120 client-side image map. The USEMAP attribute can be used with the 121 ISMAP attribute to indicate that the image can be processed as 122 either a client-side or server-side image map. The argument to 123 USEMAP specifies which map to use with the image, by specifying the 124 URI for the file containing the map, followed by a '#', followed by 125 the name of the map. If the argument to USEMAP starts with a '#', 126 the map is assumed to be in the same document as the IMG tag. The 127 presence of a USEMAP attribute overrides the effect of an enclosing 128 anchor (A) element. 130 The different regions of the image are described using a MAP 131 element. The map describes each region in the image and indicates 132 where it links to. The basic format for the MAP element is as 133 follows: 135 136 138 140 The NAME attribute specifies the name of the map so that it can be 141 referenced by an IMG element. Each AREA element contained inside 142 the map element specifies a single clickable area of the image. 143 The SHAPE attribute gives the shape of this area. Possible shapes 144 are "RECT", "CIRCLE", and "POLYGON", which specify rectangular, 145 circular, and polygonal regions respectively. If the SHAPE tag is 146 omitted, SHAPE="RECT" is assumed. 148 The COORDS tag describes the position of an area, using image 149 pixels as the units with the origin at the upper-left corner of the 150 image. For a rectangle, the coordinates are given as 151 "left,top,right,bottom". The rectangular region defined includes 152 the lower-right corner specified, i.e. to specify the entire area 153 of a 100x100 image, the coordinates would be "0,0,99,99". 155 For a circular region, the coordinates are given as 156 "center_x,center_y,radius", specifying the center and radius of the 157 circle. All points up to and including those at a distance of 158 "radius" points from the center are included. For example, the 159 coordinates "4,4,2" would specify a circle which included the 160 coordinates (2,4) (6,4) (4,2) and (4,6). 162 For a polygonal region, the coordinates specify successive 163 vertices of the region in the format "x1,y1,x2,y2,...,xn,yn". 164 If the first and last coordinates are not the same then a segment 165 is inferred to close the polygon. The region includes the 166 boundary lines of the polygon. For example, "20,20,30,40,10,40" 167 would specify a triangle with vertices at (20,20) (30,40) and 168 (10,40). No explicit limit is placed on the number of vertices, 169 but a practical limit is imposed by the fact that HTML limits 170 an attribute value to 1024 characters. 172 The NOHREF attribute indicates that clicks in this region should 173 perform no action. An HREF attribute specifies where a click in 174 that area should lead. A relative anchor specification will be 175 expanded using the URI of the map description as a base, rather 176 than using the URI of the document from which the map description 177 is referenced. If a BASE tag is present in the document containing 178 the map description, that URI will be used as the base. 180 An arbitrary number of AREA tags may be specified. If two areas 181 intersect, the one which appears first in the map definition takes 182 precedence in the overlapping region. Multiple areas may share the 183 same destination to create composite shapes. Any portion of an 184 image which is not described by an AREA tag defaults to having no 185 action. 187 The ALT attribute specifies optional text which describes a given 188 area. A text-only browser can display the textual contents for 189 each area as a substitute for the image. 191 2.2 Required Changes to HTML/2.0 DTD 193 The required changes to the HTML/2.0 DTD to support this syntax 194 would be as follows: 196 Change the IMG element definition to be: 197 198 #AttVal(Alt)" 205 > 207 Add the following new definitions: 208 209 213 214 222 2.3 Backwards Compatibility 224 This extension is specifically designed to provide a variety of 225 fallback options for browsers which do not support it. These 226 options are based on the assumption that browsers will ignore any 227 attributes or elements which are not present in the HTML/2.0 DTD. 229 An document can be written so that a client-side image map can have 230 three different fallback behaviors. First, the document can use 231 the server-side image map capability, by specifying the ISMAP 232 attribute as well as USEMAP. In situations where this is possible, 233 the image map will work whether or not the browser supports the 234 client-side extension. 236 Second, clicking the image can direct the user to a single URI, 237 regardless of where on the image he clicks. This is accomplished 238 by placing the image inside an anchor (A) element. The fallback 239 destination could provide the user with an error or a textual list 240 of destinations. 242 Lastly, the image can appear to not be a link at all (i.e. missing 243 whatever visual cues a browser provides to indicate a hyperlink). 244 This will be the result if the image element neither contains an 245 ISMAP attribute nor is inside an anchor. 247 2.4 Examples 249 The following three examples show markup demonstrating the three 250 fallback mechanisms described in section 2.3: 252 This image map will work with any graphical browser: 253 254 256 Clicking here will take you to a page with an error message if 257 you don't have client-side image map support: 258 259 261 You can only click here if your browser supports client-side 262 image maps: 264 The following example shows the use of a map in the same file as 265 the image: 267 269 The following example defines a simple map which describes an 270 image with a circle in the middle overlapping two large 271 rectangles: 273 274 About our company 276 Our products 278 Technology for the next century 280 282 3. Security Considerations 284 Clicking a portion of a client-side image map may cause a URI 285 to be dereferenced. In this case, the security considerations 286 related to URLs [5] apply. 288 4. References 290 [1] T. Berners-Lee, D. Connolly. "HyperText Markup Language 291 Specification - 2.0" RFC 1866, November 1995. 293 [2] J. Seidman, "An HTML Extension to Support Client-Side Image 294 Maps" The Second Internation WWW Conference '94 Advance 295 Proceedings, pp 927-930. 297 [3] "Standard Generalized Markup Language" ISO Standard 8879:1986 298 Information Processing Text and Office Systems. 300 [4] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen, 301 "Hypertext Transfer Protocol -- HTTP/1.0" Internet-Draft 302 (work in progress), March 8, 1995. 304 [5] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 305 Resource Locators (URL)", RFC 1738, December 1994. 307 5. Author's Address 309 James L. Seidman 310 jim@spyglass.com 311 Senior Software Engineer 312 Spyglass, Inc. 313 1230 East Diehl Road 314 Naperville, IL 60563