From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.5+) Gecko/20011106
XHTML 1.0 has deprecated <map name="foo"> in favor of <map id="foo">.
However, given a client-side image map declared as <map id="foo">,
referencing it with <img src="..." alt="..." usemap="#foo" /> does
not work at all.
Steps to Reproduce:
1. Start Mozilla.
2. Open the forthcoming test case.
3. Wave the mouse pointer over the image.
4. Click the Z.
Actual Results: Hand cursor over entire image; nothing is clickable.
Expected Results: Hand cursor over only the 'z';
clicking the 'z' takes you to the Mozilla.org homepage.
IE 6.0 (Win32) implements the expected behavior for both samples. Before
you conclude that this is not a bug, consider that using <map name="foo">
instead of <map id="foo"> causes a page not to validate.
Created attachment 57320 [details]
Test case showing actual behavior and a simulation of expected behavior
See bug 51339.
*** Bug 109385 has been marked as a duplicate of this bug. ***
The attached testcase was HTML. Changing the mime type to an XML mime type shows
that the page is not well-formed XML.
Created attachment 57328 [details]
Test case, cleaned up to be well-formed. This attachment makes attachment 57320 [details] obsolete.
This test case fixes the previous test case's & problems. However, I don't
have permission to mark my previous attachment as obsolete.
(Off topic: I see the fact that Bugzilla displays the Obsoletes checkboxes
for users who do not have permission to mark attachments as obsolete as a
bug in the Bugzilla product.)
I've also renamed the file on my server to reflect its xhtml nature.
The cleaned up patch shows the correct behavior - in the first image the 'z' is
the hotspot. The second image on the other hand does not work, because it uses
the deprecated name attribute.
Marking as INVALID.
If you think we should support the name attribute, you should open a new
enhancement request for that.
I see incorrect behavior for MIME type text/html and correct behavior for
text/xml. However, some ISPs and hosting services have no way of sending a
page as MIME type text/xml. Should this bug be reopened, depending on tech
evangelism meta-bug 109837?
> I see incorrect behavior for MIME type text/html and correct behavior for
> text/xml. However, some ISPs and hosting services have no way of sending a
> page as MIME type text/xml.
I write all my sites as XHTML 1.0 Strict, but I send a content-type of
"text/html" because IE refuses to render them if I send "text/xml". Even if the
content-type is "text/html", there is NO reason for Mozilla not to support the
Comment on attachment 57320 [details]
Test case showing actual behavior and a simulation of expected behavior
Since this bug morphed, changing the mime type to HTML so we have the testcase
both with HTML and XML mime type.
A document sent with mime type text/html having XHTML doctype is treated as HTML
4.01 in strict mode.
HTML 4.01 states about the usemap attribute on IMG: "This attribute associates
an image map with an element. The image map is defined by a MAP element. The
value of usemap must match the value of the name attribute of the associated MAP
It would be an error to match an id attribute in HTML.
You are setting yourself up for problems if you serve XML documents with HTML
mime type, or vice versa.
The workaround, if you serve XHTML with text/html mime, type is to use both id
and name attributes.
XHTML 1.0 states: "XHTML Documents which follow the guidelines set forth in
Appendix C, "HTML Compatibility Guidelines" may be labeled with the Internet
Media Type "text/html", as they are compatible with most HTML browsers."
I read this as "If and only if a document follows Appendix C may it be served
with text/html mime type." Appendix C recommends, among other things, to use
both id and name attributes. My take that this is "if and only if" is my
interpretation only, and there seems to be a lot of confusion around this issue,
see for example http://lists.w3.org/Archives/Public/www-html/2001Oct/0065.html
The way I read the spec is that nothing is guranteed to work when the file is
served as text/html but the guidelines in appendix-C should help get the xhtml
document working in older browsers. The question here on the other hand is if
mozilla should support xhtml as much as possible when it is served as text/html
> The question here on the other hand is if mozilla should support xhtml
> as much as possible when it is served as text/html
I see no reason why not to follow the doctype over the MIME type. Content
creators have much more control over doctypes than over MIME types (which only
root can change). Rendering a bytestream marked as XHTML in quirks mode (with
all the associated differences from the CSS box model) is NOT OK because it may
make content creators think quirks mode is normal for XHTML.
I see the MIME type text/html as referring to HTML, not necessarily SGHTML (i.e.
HTML implemented on SGML such as HTML 3.2 or HTML 4.01). Right now, Mozilla
correctly follows HTML 4 doctypes but ignores XHTML doctypes entirely. Given
that NO web site on the public Internet will serve text/xml (which would make
another popular browser refuse to render it) and that the standard does not
prohibit servers from marking XHTML as text/html (in fact, the standard doesn't
specify a MIME type for XHTML at all), it appears that XHTML served as text/html
will become the de facto standard.
Before you morph this back into evangelism, consider this: If we refuse to
render text/html XHTML as XHTML, then how can a content creator create XHTML
that will work on both IE and Mozilla?
While the HTML WG hasn't made an explicit declaration, they've been dropping
fairly strong hints to our standards people that Heikki's interpretation of
Appendix C is correct. Most of that has been directed towards the expectation
that XHTML XML features won't work when it's served as HTML, but this could just
as well cleave the other way. I believe that compatibility features such as the
id="foo" name="foo" trick are only available in the XHTML Transitional DTD.
Honestly, there is no point in serving XHTML as text/html. The only thing
gained by changing from HTML 4.01 to XHTML is interoperability with XML tools,
and that is lost when serving it as something other as text/xml,
application/xml, or application/xml+xhtml (or whatever the new proposed
(FWIW, if you're hosted on Apache and it's reasonably configured, MIME-type
configuration by users is indeed possible.)
Closing again as INVALID to get this off my radar. If the W3C specs state what
we are doing is incorrect I'll reconsider, but so far it looks like I am correct.
> I believe that compatibility features such as the id="foo" name="foo"
> trick are only available in the XHTML Transitional DTD.
XHTML 1.0 does allow the name attribute on map in both Transitional and Strict.
XHTML 1.1 does not.
This makes it impossible to write XHTML 1.1 documents with image maps that can
be used in both IE and Mozilla. But it's Microsoft's bug, not Mozilla's, so
*** Bug 143616 has been marked as a duplicate of this bug. ***
*** Bug 148438 has been marked as a duplicate of this bug. ***
*** Bug 180959 has been marked as a duplicate of this bug. ***
So in essence, you're making it impossible for current html authors to use xhtml
1.1 for any realistic purpose, even as a intranet application, if they use
mozilla/netscape and ie - that's a big win for standards, and mozilla in
general...perhaps you may want to think about what you're trying to accomplish
> So in essence, you're making it impossible for current html authors to use xhtml
> 1.1 for any realistic purpose, even as a intranet application, if they use
> mozilla/netscape and ie
Uhm, no, *Microsoft* (by not supporting XHTML) are making it impossible for
current html authors to use xhtml 1.1 for any realistic purpose, even as a
intranet application, if they use mozilla/netscape and ie.
Be realistic...idealism is nice but if things aren't at least partially
compatible until the big bad microsoft catches up, people aren't going to write
things completely standards compatible, and people never will. They'll write
for the moneymaker, IE. A company is not going to dump IE for mozilla because
the local techie wants to use xhmtl and xml stuff... And it's one thing to bend
all your standards so they match IE, it's another to simply make an imagemap be
referred by id when the doctype is set to xhtml 1.1
*** Bug 190591 has been marked as a duplicate of this bug. ***
*** Bug 194286 has been marked as a duplicate of this bug. ***
*** Bug 201636 has been marked as a duplicate of this bug. ***
*** Bug 266134 has been marked as a duplicate of this bug. ***
*** Bug 193569 has been marked as a duplicate of this bug. ***
*** Bug 251902 has been marked as a duplicate of this bug. ***
*** Bug 262155 has been marked as a duplicate of this bug. ***
*** Bug 123182 has been marked as a duplicate of this bug. ***
*** Bug 235422 has been marked as a duplicate of this bug. ***
*** Bug 276651 has been marked as a duplicate of this bug. ***
*** Bug 245717 has been marked as a duplicate of this bug. ***
Adding the following just in case it was not explained in that way.
*** Bug 285905 has been marked as a duplicate of this bug. ***
Shouldn't this bug be reopened?
This is a stupid issue that breaks compatibility on various XHTML-validated
sites, damaging only Firefox when all other browser works...
*** Bug 317346 has been marked as a duplicate of this bug. ***
*** Bug 343301 has been marked as a duplicate of this bug. ***
Reopen this bug!
This behaviour is NOT conforming with W3.
It is a simple correction and should help many users that uses imagemaps.
(In reply to comment #17)
> Closing again as INVALID to get this off my radar. If the W3C specs state what
> we are doing is incorrect I'll reconsider, but so far it looks like I am correct.
Closing something as INVALID because you're tired of seeing it? What the **** is this? Did you even *READ* this bug thoroughly? The W3 specs state you ARE IN FACT DOING IT INCORRECTLY. Read the specification, read the bug. Once you've done that, I want you to go back and read the specification again, and read the bug again. Keep doing that until you realise your mistake. And in the meantime, re-open this.
URL is no longer valid. I've been out of college for three and a half years.
*** Bug 351023 has been marked as a duplicate of this bug. ***
(In reply to comment #42)
> (In reply to comment #17)
> > Closing again as INVALID to get this off my radar. If the W3C specs state what
> > we are doing is incorrect I'll reconsider, but so far it looks like I am correct.
> Closing something as INVALID because you're tired of seeing it? What the fuck
No, I closed this as invalid because in my (and many others including bz) opinion this bug is invalid and what we are doing is correct per the spec.
Also note that I marked this bug invalid 4.5 years ago, and nobody who has the power to do so has reopened it since then.
However, due to number of dupes this seems to be a frequent cause of confusion. Perhaps the spec has been updated or there is a new errata, or perhaps other browsers have been implemented differently. I don't know - I haven't been actively involved in Mozilla's XML/HTML support in 3 years.
Reopening. I will reassign to default component owner so that whoever is the current maintainer of this area can make a new call as to whether Mozilla's behavior should be changed or if this should be marked invalid (again).
Let's keep the comments civil and on topic.
*** Bug 353198 has been marked as a duplicate of this bug. ***
Ian, care to comment on the WHATWG approach to this?
For what it's worth, I should point out that our current behavior is EXACTLY what the W3C spec says. The duplicates are due to people violating the XHTML spec in their pages (serving XHTML that doesn't comply with XHTML 1.0 Appendix C as text/html). Now we might want to introduce a deviation from the de-jure spec to deal with de-facto problems. But that's not something to do lightly.
As for comment 42, I strongly encourage Jeremy to read the specs in question carefully and then read this bug, since he seems to be a little confused about what the specs say. He does seem to have a strong opinion about what the specs _should_ say, but that's something to take up with the W3C.
Unless someone gives a good reason not to, WHATWG is going to say that usemap is a string that must begin with a "#" character, and then be followed by a string that must be used to find the first matching <map> element with a "name" attribute of the given string. In particular, none of this is going to involve ID-type attributes, none of it is going to involve URIs, and none of it is going to be different between HTML and XHTML.
I can't tell exactly what this bug is asking for, FWIW.
> I can't tell exactly what this bug is asking for, FWIW.
This bug is asking that:
<map id="foo"> ... </map>
work in XHTML served as text/html. Currently in Gecko it works in application/xhtml+xml but not in text/html.
*** Bug 389065 has been marked as a duplicate of this bug. ***
The current state of the HTML 5 spec is significantly different from what Hixie said in comment 48.
Given the current state of the spec and Gecko (and WebKit), a text/html document with client-side image maps cannot both work in Gecko (and WebKit) and conform to the spec.
Henri, that would sound like a bug in the spec, since what Gecko and webkit do for text/html and name="" imagemaps is pretty interoperable with the web and other UAs.
I agree that the spec needs changing:
Still, if IE and Opera also match on id='', perhaps Gecko and WebKit should, too.
IE always treats name and id interchangeably (including for getElementById purposes). I don't think we want to go there.
But yes, if HTML5 updates HTML in this respect, we can change from the HTML4 behavior to the HTML5 behavior.
I'm new to this, and I wanted to show my support for fixing this bug; As it does produce invalid xhtml strict 1.1. IE supports the id only "right way." Found a nice little summary here: http://randsco.com/index.php/2005/06/03/invalid_imagemaps_in_xhtml_1_1
I have an XHTML 1.1 page, served correctly as application/xhtml+xml, and validating OK. Yet the image map does not work!
This should work in XHTML 1.1...
<map id='map_shooterbot_build_3_1of14' >
<img ... usemap='map_shooterbot_build_3_1of14' ... />
It would be really great if someone could fix this issue.
The situation described in comment 57 should work fine and has nothing to do with this bug. If it's not working, please file a separate bug and attach a testcase to it. cc me on that bug.
Ah, the issue in comment 57 is the missing '#' in the usemap. It's required by XHTML 1.0, and we don't actually implement XHTML 1.1 (and neither does anyone else). application/xhtml+xml is treated as XHTML 1.0. See bug 290422.
Might be worth checking what the HTML5 spec says about this, though.
(In reply to comment #59)
> Ah, the issue in comment 57 is the missing '#' in the usemap. It's required by
> XHTML 1.0, and we don't actually implement XHTML 1.1 (and neither does anyone
> else). application/xhtml+xml is treated as XHTML 1.0. See bug 290422.
> Might be worth checking what the HTML5 spec says about this, though.
The HTML5 spec is irrelevant in this situation as we are referencing XHTML 1.0/XHTML 1.1 in this bug. If we would reproduce this bug with a DOCTYPE other than that [HTML 4.01], it would be considered a separate case. And in that case, it would work because we would use the NAME attribute instead of ID.
> The HTML5 spec is irrelevant in this situation as we are referencing XHTML
> 1.0/XHTML 1.1 in this bug.
1) The HTML5 spec contains errata for XHTML specifications and that working
group is tasked with further development of XHTML, as part of HTML5. So it is
in fact relevant.
2) This bug is specifically about HTML, not XHTML. See the summary.
3) XHTML 1.0 and XHTML 1.1 differ, unintentionally, in terms of their treatment
of usemap. See the discussion in bug 290422. Please don't lump them
together, until the errata to XHTML 1.1 that didn't manage to get published
4) All dispatch in Gecko is based on MIME type. The DOCTYPE is ignored
entirely, except for the decision in text/html as to whether to go into
quirks mode or not. In particular, all application/xhtml+xml documents are
processed identically, regardless of DOCTYPE.
5) Discussion of XHTML really doesn't belong in this bug (see item 2 above and
1. So do you wish to imply that any and all DOCTYPE are the same? That there is no distinguishable difference between HTML 4, XHTML 1.0, HTML5; Thus no use for such different standards!?
2. "The... essential difference between XHTML and HTML is that XHTML must be well-formed XML, while HTML need not be." Damian Yerrick, the original bug filer, stated this bug was with XHTML 1.0 (See https://bugzilla.mozilla.org/show_bug.cgi?id=109445#c0).
3. Okay then! XHTML 1.0 were talking about. NOT HTML5!
4. "... except for the decision in text/html as to whether to go into quirks mode or not." And even if there all processed identically, when you serve application/xhtml+xml documents, they are subjected to stricter validation.
Those rules state that said referenced image maps will be served via ID. That is the bug. Read the bug. Or can you reproduce said bug, non buggy. I bet all following will be please to hear it, since that is why they are following.
We are talking about referencing said image map based on ID, and how this is the only way to do so on XHTML 1.0, Right!? Regardless of whatever they decide to do with HTML5, or for that matter, XHTML8.96.
> 1. So do you wish to imply that any and all DOCTYPE are the same?
From the point of view of all existing web browsers... yes.
> the original bug filer, stated this bug was with XHTML 1.0
Which was being sent as text/html, hence treated as HTML4. Please read XHTML 1.0 Appendix C for details.
> 3. Okay then! XHTML 1.0 were talking about. NOT HTML5!
Irrelevant, to a web browser.
Referencing image maps by ID works fine in an application/xhtml+xml document, if you have id="foo" on the <map> and usemap="#foo" on the <img>. Now can we please stop adding noise to this bug, which is about making that exact markup _also_ work in text/html documents?
Created attachment 433551 [details] [diff] [review]
Comment on attachment 433551 [details] [diff] [review]
Ms2ger, can you please link me to the relevant part of the html5 draft so I can compare what you implemented to it?
Past that, please use the existing mochitest hooks for event dispatch (EventUtils.js) instead of making up your own clickImage.
(In reply to comment #65)
> (From update of attachment 433551 [details] [diff] [review])
> Ms2ger, can you please link me to the relevant part of the html5 draft so I can
> compare what you implemented to it?
<http://www.whatwg.org/html/#rules-for-parsing-a-hash-name-reference> (as referenced by <http://www.whatwg.org/html/#processing-model>). The returned element might not be the first one if elements are added via the DOM, but that's another bug (see <http://mxr.mozilla.org/mozilla-central/source/content/html/document/src/nsHTMLDocument.cpp#1164>).
I'll look at EventUtils.
Thank you. The C++ looks good given that.
> but that's another bug
Indeed. Want to file and fix? Just using a content list for imagemaps should work, I'd think.
Might be good to add a test at least for the static case of the "take the first matching <map>" thing.
Created attachment 435222 [details] [diff] [review]
Comment on attachment 435222 [details] [diff] [review]
Stealing bz's review request. r=jst