Last Comment Bug 189643 - Allow USEMAP attributes to reference MAP elements in other documents
: Allow USEMAP attributes to reference MAP elements in other documents
Status: VERIFIED WONTFIX
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P5 enhancement with 4 votes (vote)
: Future
Assigned To: layout
: Hixie (not reading bugmail)
Mentors:
http://greg.tcp.com/mozilla/map/
Depends on: 1882
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-18 20:22 PST by Greg K.
Modified: 2007-09-03 00:28 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Greg K. 2003-01-18 20:22:58 PST
HTML defines the value of the USEMAP attribute to be URI, but Mozilla only
allows them to reference a MAP element in the same document as the USEMAP.

To the extent allowed by Mozilla's security specifications, USEMAPs should be
allowed to refer to MAP elements in external documents.
Comment 1 Christopher Hoess (gone) 2003-01-18 21:29:23 PST
Perhaps this should be brought up before the WG or on www-html, to see if this 
was really intended? As heikki said, this would require synchronous loading of 
HTML documents, which is a pretty tall order. (It's more complicated than, say, 
<object>, because you have to grab a *piece* from the second document and put 
it into the first, AIUI.)
Comment 2 Greg K. 2003-01-18 22:27:31 PST
Just so it's said, the application of this would be to achieve the functionality
of server-side image maps in a client-side way. Rather than including the same
client-side map in every document that needs it (such as for a common toolbar),
all the documents can link to a single, central map on the server, which can
then be cached and reaccessed by subsequent similar documents.

In a private e-mail thread, Heikki explained to me the security problems posed
by this. It seems at the least that an external document that doesn't violate
Same Origin Policy should be accessible.

As for user agents that have ever implemented this, I seem to recall that NCSA
Mosaic 3 did, and also Mac IE 4 (but not 5).
Comment 4 Rob 2005-03-13 06:29:55 PST
I found that shape="rect" works fine while shape="default" won't work propperly.
This is a relevant part of the code for the logo's on http://devakhandel.nl

<img src="devakhandel_logo2.gif" usemap="#logomap" border=0><map name="logomap">
<area shape="rect" coords="235,00,300,28"
href="http://devakhandel.nl/index.php?manufacturers_id=10">
<area shape="rect" coords="036,00,090,28"
href="http://devakhandel.nl/index.php?manufacturers_id=11">
</map>

I found a useful description and testpage on
http://www.handleidinghtml.nl/html/objecten/objecten04.html
(unfortunately it is in dutch, but the example code and testlinks speak for
themselves).

Bekijk in een nieuw VENSTER of de browser deze image map ondersteunt.
(Open an new WINDOW and see if your browser can handle this image map)
(click on VENSTER)
Comment 5 Anne (:annevk) 2005-03-13 09:00:31 PST
Comment 4 is not related to this bug. Please file a new bug if you think that is
needed. Also, do not comment if you are not completely sure it is relevant.
Comment 6 Lachlan Hunt 2007-08-20 21:50:26 PDT
This bug should be marked invalid now. HTML5 now defines the usemap attribute as a Hashed ID Reference, not a URI, and can only reference maps within the same document.

The usemap attribute:
http://www.whatwg.org/specs/web-apps/current-work/#usemap1

Hashed ID Reference:
http://www.whatwg.org/specs/web-apps/current-work/#valid7
Comment 7 Robert Burns 2007-08-20 22:12:05 PDT
(In reply to comment #6)
> This bug should be marked invalid now. HTML5 now defines the usemap attribute
> as a Hashed ID Reference, not a URI, and can only reference maps within the
> same document.

But yesterday HTML 5 defined the usemap attribute as a URI. And tomorrow... There's a reason not to quote recommendations before at least candidate recommendation status. right now HTML 5 is not even a public working draft. 
Comment 8 Hixie (not reading bugmail) 2007-08-20 22:28:48 PDT
Actually HTML5 never defined usemap as a URI, and never will. At this point we can't change this without breaking pages, and so this is (regardless of what the specs say) WONTFIX. Because of that, the HTML5 spec says what it says. It's the dog (the implementations) wagging the tail (the spec), not vice versa.
Comment 9 Robert Burns 2007-08-20 22:53:29 PDT
(In reply to comment #8)
> Actually HTML5 never defined usemap as a URI, and never will. At this point we
> can't change this without breaking pages, and so this is (regardless of what
> the specs say) WONTFIX. Because of that, the HTML5 spec says what it says. It's
> the dog (the implementations) wagging the tail (the spec), not vice versa.
> 

Except we're discussing the implementation here. So if we can't look to the spec to decide, then why bring it up? This should not be a wontfix. That's an error in the resolution.
Comment 10 Anne (:annevk) 2007-08-21 01:27:46 PDT
No, it's not. The behavior requested in comment 0 which would make Mozilla conforming per HTML4 can't be implemented, hence WONTFIX.
Comment 11 Robert Burns 2007-08-21 01:37:44 PDT
Why can't it be implemented? Wouldn't that statement need some sort of explanation to say that the won't fix is verified?
Comment 12 Anne (:annevk) 2007-08-21 02:27:23 PDT
Sites rely on usemap="foobar#baz" referring to the same document, regardless of "foobar" actually being the document. See also comment 2. Apart from those (which are the most significant), there doesn't seem to be much request for this type of functionality and it is completely unclear how this would work with the event model or how it would work in general (a detailed specification is lacking).
Comment 13 Robert Burns 2007-08-21 02:43:38 PDT
(In reply to comment #12)
> Sites rely on usemap="foobar#baz" referring to the same document, regardless of
> "foobar" actually being the document. 

I've never seen an author do that. Why would they include "foobar#baz' as the URI if 'foobar' was not the current document? Wouldn't any author doing that expect it to point to another document? If the author thought it was supposed to be an IDREF (and there has certainly been some confusion about this), then the value would contain no pound sign: just 'baz'. In any even,t this could eaasily be made to work with absolute URLs which would be easily distinguishable from IDREFs or relative URLs

> See also comment 2. Apart from those
> (which are the most significant), there doesn't seem to be much request for
> this type of functionality

This bugtracker is the venue to request functionality. Perhaps its all of the wontfix bugs we should look at, if we're looking for requests.

>  and it is completely unclear how this would work
> with the event model or how it would work in general (a detailed specification
> is lacking).

How would the event model be effected. The engine needs to retrieve the resource with the image map. If it is not available, it should fallback to the no image map behavior. If it can retrieve the resource, it can simply add it to the DOM immediately after the first element that needs it (or inside the element if its an OBJECT element), ensuring the style is set to {display: none}. Once this takes place it behaves just the same as any other client-side image map. There's no difference in the event model.
Comment 14 Greg K. 2007-08-21 09:34:26 PDT
Comment 6 is irrelevant to this bug, as Mozilla doesn’t implement HTML 5 (nor does any other browser).

Comment 10 is inaccurate. The behavior could certainly be implemented, as it has previously existed in other browsers. There is no fundamental Computer Science problem making it impossible. Rather, it’s a manpower issue; I wish I could fix it myself but I haven’t the time.

Mozilla is certainly welcome to WONTFIX whatever they want, for whatever reason, and so here we are. Client side image maps, to the ash heap of history!

Note You need to log in before you can comment on or make changes to this bug.