425621 - Usemap with IDREF not containing # is not rendered according to XHTML 1.1 spec

Status: RESOLVED INVALID

(Tech Evangelism Graveyard :: English US, defect)

Description

[Skewer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4

The URL http://postalchart.com/ is served to standards compliant browsers (i.e., not IE) as application/xhtml+xml based on whether it appears in the Accept: header. In Firefox it renders as XML and it claims to be running in standard mode.

I have an imagemap on this page in the top navigation, which has the following code:

<img src="/toplogo.png" style="width: 500px; height: 90px; border: none;" alt="PostalChart.com" usemap="nav" />
<map id="nav">
<area shape="rect" coords="40,60,199,90" href="/questions" alt="Questions" />
<area shape="rect" coords="215,60,343,90" href="/contact" alt="Contact" />
<area shape="rect" coords="362,60,454,90" href="/" alt="Home" />
</map>

Note the use of preferred map id over map name, and the lack of a # sign in the usemap attribute. This is the correct code and works in FF2.

This doesn't work in IE either, but I have a workaround in place for that specific user agent. I change the usemap from "nav" to "#nav" in that case.

If I comment out my code and send the "#nav" workaround to all browsers including FF3, FF3 then renders the imagemap as I expected it to do the first time (I reverted it after confirming my suspicion). But if I do that, it's no longer valid XHTML 1.1, to wit:

Error  Line 17, Column 104: character "#" is not allowed in the value of attribute "usemap".

…none;" alt="PostalChart.com" usemap="#nav" />

It is possible that you violated the naming convention for this attribute. For example, id and name attributes must begin with a letter, not a digit.

---

I would really like not to send a browser-specific workaround for broken standards to Firefox 3 in addition to IE... so please fix it.

Reproducible: Always

Steps to Reproduce:
1. Go to http://postalchart.com/ .
2.
3.
Actual Results:  
Nothing is clickable. (FF3b4)

Expected Results:  
Clickable imagemap (FF2)

Comment 1

[Jesse Ruderman]

According to http://ln.hixie.ch/?start=1172653243&count=1 this is a mistake in the XHTML 1.1 spec.

Comment 2

[Jesse Ruderman]

See bug 290422 for more.

Comment 3

[Skewer]

Given that the website in question does not pass the W3C validator with the "#nav" syntax, either the website is wrong or the validator is wrong. In either case Tech Evangelism is needed so I'm reopening and redirecting accordingly.

Comment 4

[Skewer]

Well, you may notice something different on the above webpage. I've put in the browser-specific workaround and a nasty message to Firefox users about non-W3C compliance. Hopefully this gets resolved before Firefox 3 replaces Firefox 2.

Comment 5

[Jesse Ruderman]

I'm not sure why you have decided to direct your anger at Firefox (for not implementing the bug in the spec) rather than at the W3C (for not fixing the bug in the spec).

Comment 6

[Skewer]

If the W3C spec is wrong, let W3C fix it. As far as W3C is concerned my page is valid. It seems like we should be getting folks from the W3C involved rather than just changing the browser to not obey the standard and leaving it at that.

Comment 7

[Daniel.S]

Jesse, I think this is more complex.

Up to Gecko 1.8.1, both IDREFs and fragment identifiers were allowed to be used. Idenpendently of XHTML version, it just had to be treated as XHTML (application/xhtml+xml).

It seems this was removed in Gecko 1.9, but I can't find a bug for this, so I'm unsure wether it was intended or by accident.

Comment 8

[Jesse Ruderman]

The patch in bug 290422 was the one the removed it in Gecko 1.9.  (Gecko 1.8 branched 2005-08-12, and the patch there landed 2005-09-29.)

Comment 9

[Andy Cowley]

The W3C spec isn't wrong, it is just different from 1.0 strict, and this is still a gecko/firefox bug. Konqueror works like it says on the tin. Firefox is not xhtml1.1 compliant for application/xhtml+xml .xhtml pages. Lots of older web pages seem to say it is, I presume they are referring to a gecko 1.8 Firefox?

Comment 10

[Daniel.S]

(In reply to comment #9)

> The W3C spec isn't wrong,

The authors of the XHTML 1.1 spec agreed this was a bug in their specification. They did not intend to fix that bug however.

> it is just different from 1.0 strict, and this is still a gecko/firefox bug.

In bug 290422 comment 38 Boris Zbarsky stated:
> ... 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

The definition of usemap makes the two XHTML versions incompatible. Since both share the same namespace, you have to decide whether to support v1.0 or v1.1

Mozilla decided for XHTML 1.0 because that is what people use on the web (less or more) and it is the forward-compatible version serving as the base for XHTML5.

Introducing conditional behaviour in XML would hurt the XML ecosystem.

> Konqueror works like it says on the tin.

I can't test, but if Konqueror allows IDREFS in usemaps in XHTML 1.0, Konqueror is incompatible to XHTML 1.0 and the web.

> Firefox is not xhtml1.1 compliant for application/xhtml+xml .xhtml pages. > Lots of older web pages seem to say it is, I presume they are referring to
> a gecko 1.8 Firefox?

Yes, In Gecko 1.8 there was a bug that made it look like it was XHTML 1.1 compliant, when it was actually icompatible to XHTML 1.0.

Closing won't fix due to the reasons stated by Boris.

This bug is no TE bug because the website linked now uses #name.

Comment 11

[Daniel.S]

Actually...  (sorry for spam)

The recently published Second Edition of XHTML Modularization 1.1 [1] finally fixed this issue. usemap is now of a new type called URIREF (#fragment-identifier).

Two incompatibilities still exist, XHTML 1.0 doesn't support ruby (XHTML5 only a subset) and XHTML 1.1 doesn't support the lang attribute (the validator has a bug about this cas though).

Correctly resolving this as Invalid, as this is no longer a bug.

[1] http://www.w3.org/TR/2010/REC-xhtml-modularization-20100729/abstract_modules.html#s_imapmodule