Closed
Bug 290422
Opened 16 years ago
Closed 16 years ago
''usemap'' attribute for IMG tags work without a needed "#" before inline maps.
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: mike, Assigned: philor)
References
()
Details
Attachments
(3 files)
236 bytes,
text/html
|
Details | |
979 bytes,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
159 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 Per the spec (http://www.w3.org/TR/REC-html40/struct/objects.html#adef-usemap), "usemap" uses a URI for the value. An inline map therefor would simply be "#mapname". However, Firefox still translates a URI with no "#" as a target location in that document. In other words, Firefox treats ''usemap="#map1"'' and ''usemap="map1"'' the same, and shouldn't. The latter should cause unpredictible results (if there's no server-side file named "map1" on the server in the current location. The correct example is at: http://www.pandahead.com/AskMordo/ - the incorrect is at the URI above. The map (for testing) is the skull on the "!" in the "Ask Mordo!" logo. Reproducible: Always Steps to Reproduce: 1.Create HTML file with an IMAGE and a MAP 2.Link IMG to the MAP using "usemap=" 3.Launch Firefox and test it. It should work. IE it won't, Opera it won't either. Actual Results: Firefox acts like I clicked on the link. Expected Results: Nothing to happen; no valid map specified. No high-treatment needed for this - As a developer, you should KNOW that a "#" is needed. When I coded a handful of pages, I had completely forgotten about that, and having tested everything in Firefox, expected it to work, when a user tried it and reported that they couldn't click on anything. Had to go back and fix my idiot mistake. :) However, it's just a little thing that, for compatibility, may cause issues in the future, or cause grief like it did to myself.
Reporter | ||
Comment 1•16 years ago
|
||
Fixed URI. Apologies.
Assignee | ||
Comment 2•16 years ago
|
||
Doesn't seem like we're being helpful, though maybe I'm missing something. In bug 1882 we got (limited) support for usemap="index.html#foo", but it only sees two possibilities: either there's a "#" in the usemap value, in which case we look for what comes after that as a map name, or there isn't, in which case we treat the whole usemap value as being the name. The first case is as right as we can be, but the second case seems destined to do nothing but mess with people's expectations, since IE and Opera both just ignore usemap="foo". Seems to me like the "if (hash > -1)" ought to have an "else return nsnull"
Assignee: firefox → nobody
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
![]() |
||
Comment 3•16 years ago
|
||
> since IE and Opera both just ignore usemap="foo".
They do? I was under the impression that IE allowed usemap="foo"... Or is that
the other way around and it allows <map name="#foo"> and referencing it via
usemap="#foo"?
Assignee | ||
Comment 4•16 years ago
|
||
They may have allowed it at one time, but I just checked both bad forms with a current IE and a current Opera, and nobody accepts name="#foo" usemap="#foo", and only we accept name="foo" usemap="foo"
Comment 5•16 years ago
|
||
And we (unlike IE) do not support <map id="foo">. Hixie, perhaps HTML5 van clarify what to do? (Like making external image maps impossible.)
Comment 6•16 years ago
|
||
The usage without the "#" was at one point allowed in XHTML but that has been errataed out of the spec.
Comment 7•16 years ago
|
||
It is in XHTML1.1: <http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/abstract_modules.html#s_imapmodule> The second edition doesn't change that either: <http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/abstract_modules.html#s_imapmodule>
Comment 8•16 years ago
|
||
And has HTML5 seems to be referring to XHTML1.1 - not really clear - I guess this should be clarified.
Comment 9•16 years ago
|
||
The HTMLWG is well-known for not updating its errata very often. However, I assure you, this is something that was unintentionally changed during the move to XHTML and the fact that it says IDREF in the XHTML specs is a mistake. It should be a URI, for compatibility with HTML.
Comment 10•16 years ago
|
||
So that Mozilla only supports it as an IDREF in application/xhtml+xml is a mistake and we should have a bug on that?
![]() |
||
Comment 11•16 years ago
|
||
> And we (unlike IE) do not support <map id="foo">.
We do, in XHTML (per spec). And we don't support name="foo" in XHTML, also per
spec. I believe this is actually correct and not affected by the IDREF/URI
issue, since URI fragment identifiers in XTHML refer to IDs. Note that IE
generally treats id="foo" and name="foo" as identical (see its handling of
getElementById, eg).
I have no problem with removing support for usemap="foo", though. Post a patch;
I'll review.
Comment 12•16 years ago
|
||
> So that Mozilla only supports it as an IDREF in application/xhtml+xml is a
> mistake and we should have a bug on that?
Isn't that this bug?
Comment 13•16 years ago
|
||
This is about text/html atm.
Comment 14•16 years ago
|
||
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Assignee | ||
Comment 15•16 years ago
|
||
-> NEW per comment 11, -> me hoping it's really as simple as I think it is.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Updated•16 years ago
|
Assignee: nobody → bugzilla
Status: ASSIGNED → NEW
Assignee | ||
Comment 16•16 years ago
|
||
Assignee | ||
Comment 17•16 years ago
|
||
Attachment #197809 -
Flags: superreview?(bzbarsky)
Attachment #197809 -
Flags: review?(bzbarsky)
![]() |
||
Comment 18•16 years ago
|
||
With that patch, how do we treat: <map name="foo" id="foo"> <img usemap="foo"> ? How do other browsers treat it?
Assignee | ||
Comment 19•16 years ago
|
||
We say: not a link, as do IE and Opera. So we would be following Hixie's comment 9, rather than the published XHTML spec. I don't have Safari or Konqueror to check - are they following the letter of the spec?
![]() |
||
Comment 20•16 years ago
|
||
So in IE <map id="foo"> <img usemap="foo"> doesn't work?
Assignee | ||
Comment 21•16 years ago
|
||
id=foo, usemap=foo, IE does indeed say "not a link" (though, again, I'm a lousy tester because I don't have IE7).
![]() |
||
Comment 22•16 years ago
|
||
Comment on attachment 197809 [details] [diff] [review] patch Compat with IE6 is quite good enough here. r+sr=bzbarsky
Attachment #197809 -
Flags: superreview?(bzbarsky)
Attachment #197809 -
Flags: superreview+
Attachment #197809 -
Flags: review?(bzbarsky)
Attachment #197809 -
Flags: review+
Assignee | ||
Updated•16 years ago
|
Whiteboard: [checkin needed]
Assignee | ||
Comment 23•16 years ago
|
||
Landed on trunk. Does anyone feel a need to see it on the branch?
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]
![]() |
||
Comment 24•16 years ago
|
||
We shouldn't put this on branch at this late date; certainly not till a lot more trunk baking happens...
Comment 25•15 years ago
|
||
*** Bug 322384 has been marked as a duplicate of this bug. ***
Comment 26•14 years ago
|
||
the fix prevents sites written with the correct XHTML 1.1 syntax (and using the correct mimetype) to use image maps, which breaks compatibility with all earlier Mozilla/Gecko browsers that got out starting in 2002. Isn't there a way to make Gecko accept both usemap="id" AND usemap="#id" when in full XHTML mode? This would allow cross-browser compatibility and still comply with standards.
![]() |
||
Comment 27•14 years ago
|
||
Please read the bug. The syntax in question is no "correct XHTML 1.1 syntax" -- it's an error in the XHTML 1.1 spec and the XHTML Working Group will at some point get off their collective asses and publish the erratum.
Comment 28•14 years ago
|
||
OK, then it may be a good idea to notify the w3c validator maintainers that their validator still enforces the incorrect XHTML 1.1 syntax, too; moreover, all versions of Mozilla (starting at Suite 1.0rc1 up to and including Firefox 2) will hiccup on a 'corrected' XHTML image map. Meaning that supporting all Gecko versions behaviours on image maps will require versioning support! Isn't there a way to support both syntaxes for back/forward compatibility?
Comment 29•14 years ago
|
||
(In reply to comment #5) > > Hixie, perhaps HTML5 van clarify what to do? (Like making external image maps > impossible.) Done.
Comment 30•13 years ago
|
||
As of today, the spec still reads IDREF, the validator still fails this syntax, and my site which is 100% valid XHTML 1.1 breaks in FF3 - bug 425621. So FF3 is therefore not standards compliant, unless the standard is changed or FF3 is changed. I don't see how we can call this "fixed" personally.
Comment 31•13 years ago
|
||
P.S. One author of the standard's opinion does not a standard make.
![]() |
||
Comment 32•13 years ago
|
||
XHTML1.1 is not really relevant here, since we don't implement it. Once HTML5 defines this, if we're not compatible with what it does please feel free to come back to this.
Comment 33•13 years ago
|
||
OK, how about XHTML 1.0? Are you going to tell me FF3 doesn't implement that either?
Assignee | ||
Comment 34•13 years ago
|
||
XHTML 1.0, which defines usemap as a URI, not an IDREF? We sure do!
Comment 35•13 years ago
|
||
Aha, sure enough. The validator isn't clear in that regard (putting "nav" in a URI field without "#" is valid but won't work for a client-side map). In any case, since when doesn't Mozilla implement the XHTML 1.1 Recommendation? The Mozilla webpage indicates otherwise.
Comment 36•11 years ago
|
||
How do I vote "against" this bug? I'd like to see it backed out.
Comment 37•11 years ago
|
||
Me too ;-) firefox/gecko is just this one bug away from supporting xhtml 1.1. Shame to force me to use css or invalid pages. booo.
![]() |
||
Comment 38•11 years ago
|
||
Andy, I'm sorry, but the XHTML working group decided to make XHTML 1.1 incompatible with XHTML 1.0. As a result we have to pick one or the other to support, and we support XHTML 1.0.
You need to log in
before you can comment on or make changes to this bug.
Description
•