109445 - Referencing a client-side image map declared with id attribute doesn't work in text/html (usemap)

Status: RESOLVED FIXED

(Core :: XML, defect)

Description

[Damian Yerrick]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.5+) Gecko/20011106
BuildID:    2001110603

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.

Reproducible: Always
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.

Comment 1

[Damian Yerrick]

Attachment: Test case showing actual behavior and a simulation of expected behavior

Comment 2

[Christopher Hoess (gone)]

See bug 51339.

Comment 3

[Christopher Hoess (gone)]

->heikki

Comment 4

[Christopher Hoess (gone)]

*** Bug 109385 has been marked as a duplicate of this bug. ***

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

The attached testcase was HTML. Changing the mime type to an XML mime type shows
that the page is not well-formed XML.

Comment 6

[Damian Yerrick]

Attachment: Test case, cleaned up to be well-formed. This attachment makes attachment 57320 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.)

Comment 7

[Damian Yerrick]

I've also renamed the file on my server to reflect its xhtml nature.

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 9

[Damian Yerrick]

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?

Comment 10

[Jonas Jørgensen]

> 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
id attribute.

Reopening.

Comment 11

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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
element."

http://www.w3.org/TR/html4/struct/objects.html#adef-usemap

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.

Comment 13

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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."

http://www.w3.org/TR/xhtml1/#media

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

Comment 14

[basic]

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

Comment 15

[Damian Yerrick]

> 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?

Comment 16

[Christopher Hoess (gone)]

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
MIME-type is).

(FWIW, if you're hosted on Apache and it's reasonably configured, MIME-type
configuration by users is indeed possible.)

Comment 17

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 18

[Jonas Jørgensen]

> 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
VERIFIED INVALID.

Comment 19

[Boris Zbarsky [:bzbarsky]]

*** Bug 143616 has been marked as a duplicate of this bug. ***

Comment 20

[Boris Zbarsky [:bzbarsky]]

*** Bug 148438 has been marked as a duplicate of this bug. ***

Comment 21

[Boris Zbarsky [:bzbarsky]]

*** Bug 180959 has been marked as a duplicate of this bug. ***

Comment 22

[Elizabeth Andersen]

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

Comment 23

[Jonas Jørgensen]

> 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.

Comment 24

[Elizabeth Andersen]

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 

Comment 25

[Ruslan Ismailov]

*** Bug 190591 has been marked as a duplicate of this bug. ***

Comment 26

[Josh Birnbaum]

*** Bug 194286 has been marked as a duplicate of this bug. ***

Comment 27

[Josh Birnbaum]

*** Bug 201636 has been marked as a duplicate of this bug. ***

Comment 28

[Bill Mason]

*** Bug 266134 has been marked as a duplicate of this bug. ***

Comment 29

[Anne (:annevk)]

*** Bug 193569 has been marked as a duplicate of this bug. ***

Comment 30

[Anne (:annevk)]

*** Bug 251902 has been marked as a duplicate of this bug. ***

Comment 31

[Anne (:annevk)]

*** Bug 262155 has been marked as a duplicate of this bug. ***

Comment 32

[Anne (:annevk)]

*** Bug 123182 has been marked as a duplicate of this bug. ***

Comment 33

[Anne (:annevk)]

*** Bug 235422 has been marked as a duplicate of this bug. ***

Comment 34

[Boris Zbarsky [:bzbarsky]]

*** Bug 276651 has been marked as a duplicate of this bug. ***

Comment 35

[:Gavin Sharp [email: [e-mail]]]

*** Bug 245717 has been marked as a duplicate of this bug. ***

Comment 36

[Michael A. Puls II]

Adding the following just in case it was not explained in that way.

http://forums.mozillazine.org/viewtopic.php?t=196510

Comment 37

[Kevin Brosnan]

*** Bug 285905 has been marked as a duplicate of this bug. ***

Comment 38

[Michele Dal Corso]

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...

Comment 39

[:Gavin Sharp [email: [e-mail]]]

*** Bug 317346 has been marked as a duplicate of this bug. ***

Comment 40

[Phil Ringnalda (:philor)]

*** Bug 343301 has been marked as a duplicate of this bug. ***

Comment 41

[Ygor Lemos]

Reopen this bug!

This behaviour is NOT conforming with W3.

It is a simple correction and should help many users that uses imagemaps.

Comment 42

[Jeremy Chadwick]

(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.

Comment 43

[Damian Yerrick]

URL is no longer valid. I've been out of college for three and a half years.

Comment 44

[Phil Ringnalda (:philor)]

*** Bug 351023 has been marked as a duplicate of this bug. ***

Comment 45

[Heikki Toivonen (remove -bugzilla when emailing directly)]

(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.

Comment 46

[Phil Ringnalda (:philor)]

*** Bug 353198 has been marked as a duplicate of this bug. ***

Comment 47

[Boris Zbarsky [:bzbarsky]]

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.

Comment 48

[Hixie (not reading bugmail)]

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.

Comment 49

[Boris Zbarsky [:bzbarsky]]

> I can't tell exactly what this bug is asking for, FWIW.

This bug is asking that:

  <img usemap="#foo"/>
  <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.

Comment 51

[Henri Sivonen (:hsivonen)]

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.

Comment 52

[Boris Zbarsky [:bzbarsky]]

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.

Comment 53

[Henri Sivonen (:hsivonen)]

I agree that the spec needs changing:
http://lists.w3.org/Archives/Public/public-html/2007Oct/0186.html

Still, if IE and Opera also match on id='', perhaps Gecko and WebKit should, too.

Comment 54

[Anne (:annevk)]

FWIW, the spec calls for matching the first element that has either an id= or name= attribute with the hashed ID reference. So it is interoperable with the web in terms of user agent processing requirements.

Comment 55

[Boris Zbarsky [:bzbarsky]]

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.

Comment 56

[pikachu]

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

Comment 57

[Christian Stewart]

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' >
...
</map>
<img ... usemap='map_shooterbot_build_3_1of14' ... />

It would be really great if someone could fix this issue.

Comment 58

[Boris Zbarsky [:bzbarsky]]

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.

Comment 59

[Boris Zbarsky [:bzbarsky]]

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.

Comment 60

[pikachu]

(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.

Comment 61

[Boris Zbarsky [:bzbarsky]]

> 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
   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
   comment 58).

Comment 62

[pikachu]

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.

Comment 63

[Boris Zbarsky [:bzbarsky]]

> 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?

Comment 64

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Attachment: Patch v1

Comment 65

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 433551 [details] [diff] [review]
Patch v1

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.

Comment 66

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

(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.

Comment 67

[Boris Zbarsky [:bzbarsky]]

> <http://www.whatwg.org/html/#rules-for-parsing-a-hash-name-reference>

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.

Comment 68

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Attachment: Patch v2

Comment 69

[Johnny Stenback (:jst)]

Comment on attachment 435222 [details] [diff] [review]
Patch v2

Stealing bz's review request. r=jst

Comment 70

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Thanks.

Comment 71

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/mozilla-central/rev/ec79552a96d6
Thanks!