Allow USEMAP attributes to reference MAP elements in other documents

VERIFIED WONTFIX

Status

()

Core
Layout
P5
enhancement
VERIFIED WONTFIX
15 years ago
10 years ago

People

(Reporter: Greg K., Unassigned)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
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.
(Reporter)

Updated

15 years ago
Depends on: 1882
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.)
(Reporter)

Comment 2

15 years ago
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).

Updated

14 years ago
Priority: -- → P5
Target Milestone: --- → Future

Updated

14 years ago
Severity: normal → enhancement
OS: MacOS X → All
Hardware: Macintosh → All

Comment 3

13 years ago
Various commentary:

- http://lists.w3.org/Archives/Public/www-html/2001Oct/0015.html
- http://lists.w3.org/Archives/Public/www-dom/2002JulSep/0085.html

Comment 4

12 years ago
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

12 years ago
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

10 years ago
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

10 years ago
(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. 
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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX

Comment 9

10 years ago
(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

10 years ago
No, it's not. The behavior requested in comment 0 which would make Mozilla conforming per HTML4 can't be implemented, hence WONTFIX.
Status: RESOLVED → VERIFIED

Comment 11

10 years ago
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

10 years ago
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

10 years ago
(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.
(Reporter)

Comment 14

10 years ago
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!
You need to log in before you can comment on or make changes to this bug.