usemap referencing external map definitions

The message at the following link introduces some issues we've encountered with the usemap attribute of IMG and OBJECT.

The issues relate to usemap referencing an external html file containing the MAP information, and, in part, how those imported elements exist within the DOM environment of the host document. We have encountered multiple implementation issues related to correct DOM support of what is largely a feature of convenience.

For context, I am including the relevant portion of that message below. The developer Tantek references in the blockquote is me.

Brad Pettit


Date: Fri, 26 Jul 2002 19:56:26 -0700
From: Tantek elik <>
To: <>
Message-ID: <>
Subject: Re: HELP: XHTML 1.1 and usemap's value (PR#650)

We have been attempting to implement external (non-local) image maps
accessed via a URL in the usemap attribute and have run into a number of

I would like to share the following analysis and implementation experience
from one of our developers:


The usemap attribute is defined as a uri, like the href of an anchor.
Although it is described in the HTML 4 spec as if it's a URI fragment that
specifies a name within the same document, the HTML 3.2 DTD includes this

       "USEMAP points to a MAP element which may be in this document or an
external document, although the latter is not widely supported."

and for MAP, the spec says:

        "These can be placed in the same document or grouped in a separate
document although this isn't yet widely supported."

In HTML 4, the content model of MAP was changed to allow block-level content
and anchors in addition to AREA elements.

(From here on I'll refer to MAP elements as being INTERNAL or EXTERNAL based
on whether they come from the same document or a different address.)

Implementing based on the HTML 3.2 spec was quirky at best in that it was
unspecified as to how the external MAP elements related to the document tree
[from which they were referenced]. If the external MAP appeared in the
document tree, then it would not be clear where in the document flow the
nodes would exist. 

Other issues included whether the base url of the external document that
specified the MAP elements was to be used to resolve links, what elements
were allowed within the external document (sometimes complete HTML files
were referenced), how names in the external document were resolved ... you
get the picture.

With HTML 4, the ability to include block-level content and A tags in MAP
means there are even more unresolved issues involving style-cascade,
position within the document, and DOM interaction with external MAPs. XHTML
complicates this with validation issues (Does the external MAP file have to
validate as a full [X]HTML file?).

My suggested resolution is that external MAPs be deprecated in HTML 4
[errata] and XHTML.


In short, had HTML4 (or XHTML 1.0 or XHTML 1.1) gone through a more thorough
CR period where we required two or more shipping interoperable tested (by
way of a test suite) implementations of every feature (including external
image maps), it would have been quickly demonstrated that there were
numerous unresolved issues/problems (as described above) with external image
maps, and thus they would have been dropped during the CR period.

I propose the following:

1. KEEP the usemap attribute as IDREF as it is in XHTML 1.1 and
modularization.  Make sure this continues in XHTML 2.0.

2. Deprecate/obsolete external image map support in the HTML4.01 and XHTML
1.0 errata as a proposed change.

3. Change the type of usemap to IDREF in the HTML4.01 and XHTML 1.0 errata
as a proposed change.

4. Add some normative text to the description of usemap attribute stating

"A leading hash '#' should be permitted, even encouraged, for legacy
reasons. A leading hash should be skipped by new implementations."

I believe this proposal:

1. Makes usemap "fully implementable".

2. Maintains backward compatibility with current usage of usemap.  In
practice I have never seen an external image map except on Masayasu's test



Received on Friday, 23 August 2002 17:07:35 UTC