Closed Bug 754640 Opened 14 years ago Closed 14 years ago

The "usemap" attribute of the <img /> element doesn't work without a hash mark, but using a hash mark is invalid in XHTML 1.1.

Categories

(Firefox :: Untriaged, defect)

Product:
Firefox
Component:
Untriaged
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: 0gb.us, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0 Build ID: 20120420145725 Steps to reproduce: I attempted to use image maps in a way that did not invalidate my document. Actual results: Image maps don't work without a hash mark in the "usemap" attribute's value. However, use of the hash mark in the "usemap" attribute's value is invalid in XHTML 1.1. Expected results: Image maps should work without the hash mark, as hash marks are invalid in "usemap" attribute values in XHTML 1.1. As you can see with this validator, hash marks are invalid. http://www.validome.org/lang/en/get/http://0gb.us/
Oops, let me rephrase: the hash mark is invalid unless a "name" attribute is specified on the <map />, but the "name" attribute is invalid for <map /> elements.
There is no bug. There was a bug in XHTML Modularization that prohibited the usemap attribute to contain a hash sign. However, this bug was fixed in mid-2010. [1] usemap attributes that don't contain a #reference are invalid. The W3C Validator will tell you that your document is perfectly fine (Firefox, IE and Opera will support the combination of map@id and img@usemap=#ref). The Validator you use appears to be outdated. Note that Chrome (and Safari) still need the name attribute on the map element which is not allowed in XHTML 1.1. It is, however, allowed in XHTML 1.0 Strict and XHTML5. [1] XHTML™ Modularization 1.1 - Second Edition, 5.8. Client-side Image Map Module http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_imapmodule
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Also see the discussion in bug 290422.
Safari does NOT need the "name" attribute, or a hash mark, at least when sent as an "application/xhtml+xml" with an XHTML 1.1 <!DOCTYPE>, as I do. I just pulled Safari open to check. I also just downloaded Chrome, and ran my hash-less, "name"-less page through it, and it works as well. FireFox is the only one I've found with the problem. Bug report 290422 is either not referring to XHTML 1.1, or was incorrectly reported as a bug, when it was not. If you don't want to fix it, I won't push the issue any further, but I would like to draw your attention to an article before I leave. http://ln.hixie.ch/?start=1172653243&count=1 "The issue was once again reported in 2004 by Bjoern Hoehrmann. This time, the working group replied (in secret) that they had decided that it wasn't in fact an error, but that it would be changed in future versions of XHTML, just not in the XHTML 1.1 version. (No trace of Tantek's proposal remaining.)" Specifically, they "replied (in secret) that they had decided that it wasn't in fact an error". "It was once again reported in 2006 by Anne van Kesteren. There, the working group said they agreed "in principle" (and in secret) but that they would do the change in a later version, rather than fixing the XHTML 1.1 specification. Anne made it clear that this wasn't satisfactory, but the working group dismissed (secretly) his concerns saying it was the group's explicit goal not to fix problems while they updated the specification." Specifically, they said "that they would do the change in a later version, rather than fixing the XHTML 1.1 specification." According to the article, the working group was aware of the issue, but it was NOT, in fact, an error in the specification. They have switched back to the original implementation for future versions, but in XHTML 1.1, a hash symbol is, and is supposed to be, invalid.
What XHTML1.1 claims is irrelevant. The relevant specification is <http://www.whatwg.org/html>.
That is the HTML specification, not the XHTML specification. If I am correct, that defines HTML5, a new, yet incomplete specification. New specifications don't render old specifications invalid, especially before said new specifications are complete. That's why we have <!DOCTYPE>s, so we can specify which specification we adhere to. Like I said, if you don't want to fix it, I won't push, but if you try to show invalid evidence that it's not a bug in FireFox, I will counter with my own evidence.
That said, if you give valid evidence, I'll admit my error.
(In reply to 0gb.us from comment #4) > Safari does NOT need the "name" attribute, or a hash mark, at least when > sent as an "application/xhtml+xml" with an XHTML 1.1 <!DOCTYPE>, as I do. Sorry for this mistake. Safari and Chrome appear to distinguish between standard HTML/XHTML documents (HTML 4.01, XHTML 1.0, (X)HTML5) and XHTML 1.1 documents. Safari and Chrome are still buggy because per HTML5 both id and name attribtes have to be taken into account when processing client side image maps. > Bug report 290422 is either not referring to XHTML 1.1, or was incorrectly > reported as a bug, when it was not. In the past, Firefox supported the usemap attribute as defined in both HTML and XHTML 1.1; However, because the XHTML 1.1 definition was considered a bug, the XHTML 1.1 implementation was removed from Firefox. > If you don't want to fix it, I won't push the issue any further, but I would > like to draw your attention to an article before I leave. There is nothing to fix, please understand. > http://ln.hixie.ch/?start=1172653243&count=1 > According to the article, the working group was aware of the issue, but it > was NOT, in fact, an error in the specification. They have switched back to > the original implementation for future versions, but in XHTML 1.1, a hash > symbol is, and is supposed to be, invalid. That article is outdated as well. The XHTML WG has published a Second Edition of XHTML 1.1 [1] which is based on the Second Edition of XHTML Modularization 1.1 [2]. That document states that the usemap attribut is of type URIREF [3] which is defined as "A relative URI consisting of only an initial '#' and a fragment identifier." [4]. Is that proof enough that Firefox is correctly implementing XHTML 1.1's usemap attribute? [1] http://www.w3.org/TR/xhtml11/ [2] http://www.w3.org/TR/xhtml-modularization/ [3] http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_imapmodule [4] http://www.w3.org/TR/xhtml-modularization/abstraction.html#dt_URIREF (In reply to Ms2ger from comment #5) > What XHTML1.1 claims is irrelevant. The relevant specification is > <http://www.whatwg.org/html>. That's not quite correct. HTML5 builds on HTML 4.01 and XHTML 1.0 but not on XHTML 1.1 [5]. However, at this point in time, there is almost no difference between XHTML 1.0 Strict and XHTML 1.1. The XHTML WG has fixed most issues in XHTML 1.1. [5] http://www.w3.org/TR/html5/introduction.html#scope (In reply to 0gb.us from comment #6) > That is the HTML specification, not the XHTML specification. HTML5 is a vocabulary that defines both HTML5 and XHTML5. It is intended to supersede HTML 4.01 and XHTML 1.0. This process is almost complete. > New specifications don't render old specifications invalid, especially > before said new specifications are complete. That's why we have <!DOCTYPE>s, > so we can specify which specification we adhere to. Sorry to correct you, but you're mistaken: 1. New Specifications are able to supersede older specifications. That was the case when HTML 4.01, CSS 2.1 and XHTML 1.1 Second Edition superseded HTML 4.0, CSS 2.0 and XHTML 1.1 (First Edition) respectively. You are insofar correct that XHTML 1.1 is not technically superseeded by XHTML5, because XHTML 1.1 is a different branch of XHTML 1.0. However, as I explaned before, XHTML 1.0 Strict and XHTML 1.1 (Second Edition) are almost identical specifications at this point in time. That's because after XHTML 2.0 was discontinued, the XHTML WG finally decided to admit the mistakes the had made and to fix them. I have given you the links to the relevant parts of the specifications above. Please look them up. 2. Doctypes are relevant information for validation and the doctype switch (which doesn't apply to XHTML documents). They don't (or should not like in WebKit's case) bring magic into the game. I hope this cleans up the mess I've made myself responsible for.
Clearly I am a little behind the times. For the past month, I've been wrestling with Internet Explorer's inadequacies, so I guess I was too quick to blame the browser (FireFox, in this case) this time, when FireFox wasn't the problem. Sometimes I put too much faith in validators as well. FireFox has always (as far as I know) been a standards compliant browser, and I should have trusted it. It seems odd to me that a specific version of XHTML, or anything, really, would be replaced by another version with the same number. It seems like version numbers should be unique, and once a stable version has an official number, it seems like that version should remain unchanged. Since the specification was changed, it seems like they should have assigned it a new version number. But that's not really my choice to make. Not that it's a valid excuse, but the fact that they redefined a specific numbered version is a big part of what caused my misunderstanding. Anyway, I'm sorry to have wasted everybody's time on this one. Thanks for humoring me and my lunacy.
You need to log in before you can comment on or make changes to this bug.