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

RESOLVED FIXED

Status

()

Core
XML
RESOLVED FIXED
16 years ago
3 years ago

People

(Reporter: Damian Yerrick, Assigned: Ms2ger)

Tracking

({html5, xhtml})

Trunk
html5, xhtml
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

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

Comment 1

16 years ago
Created attachment 57320 [details]
Test case showing actual behavior and a simulation of expected behavior
See bug 51339.
Status: UNCONFIRMED → NEW
Component: Event Handling → XML
Ever confirmed: true
Keywords: xhtml
->heikki
Assignee: joki → heikki
QA Contact: madhur → petersen
*** Bug 109385 has been marked as a duplicate of this bug. ***
Attachment #57320 - Attachment mime type: text/html → text/xml
The attached testcase was HTML. Changing the mime type to an XML mime type shows
that the page is not well-formed XML.
(Reporter)

Comment 6

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

Comment 7

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

Updated

16 years ago
Attachment #57320 - Attachment is obsolete: true
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
(Reporter)

Comment 9

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

16 years ago
> 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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Updated

16 years ago
OS: Windows ME → All
Hardware: PC → All
(Reporter)

Updated

16 years ago
Depends on: 109837
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.
Attachment #57320 - Attachment is obsolete: false
Attachment #57320 - Attachment mime type: text/xml → text/html
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.
No longer depends on: 109837
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

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

Comment 15

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

(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.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → INVALID

Comment 18

16 years ago
> 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.
Status: RESOLVED → VERIFIED
*** 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. ***

Comment 22

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

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

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

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

Comment 26

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

Comment 27

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

Comment 28

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

Comment 29

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

Comment 30

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

Comment 31

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

Comment 32

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

Comment 33

13 years ago
*** 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. ***

Comment 36

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

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

Comment 37

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

Comment 38

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

Comment 41

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

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

Comment 43

11 years ago
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.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
Assignee: hjtoi-bugzilla → xml
Status: REOPENED → NEW
QA Contact: chrispetersen → ashshbhatt
*** 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:

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

Updated

10 years ago
Duplicate of this bug: 389065
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.
Summary: Referencing a client-side image map declared with id attribute doesn't work → Referencing a client-side image map declared with id attribute doesn't work in text/html (usemap)
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:
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

10 years ago
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.
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.
Assignee: xml → nobody
QA Contact: ashshbhatt → xml

Comment 56

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

8 years ago
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.
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.

Comment 60

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

8 years ago
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?
(Assignee)

Updated

7 years ago
Keywords: html5
(Assignee)

Updated

7 years ago
Attachment #57320 - Attachment is obsolete: true
(Assignee)

Updated

7 years ago
Attachment #57328 - Attachment mime type: text/xml → application/xhtml+xml
(Assignee)

Comment 64

7 years ago
Created attachment 433551 [details] [diff] [review]
Patch v1
Assignee: nobody → Ms2ger
Status: NEW → ASSIGNED
Attachment #433551 - Flags: review?(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.
Attachment #433551 - Flags: review?(bzbarsky) → review-
(Assignee)

Comment 66

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

Comment 68

7 years ago
Created attachment 435222 [details] [diff] [review]
Patch v2
Attachment #433551 - Attachment is obsolete: true
Attachment #435222 - Flags: review?(bzbarsky)
(Assignee)

Updated

7 years ago
Depends on: 564001
Comment on attachment 435222 [details] [diff] [review]
Patch v2

Stealing bz's review request. r=jst
Attachment #435222 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 70

7 years ago
Thanks.
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/ec79552a96d6
Thanks!
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago7 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.