Kimler Sidebar Menu

Kimler Adventure Pages: Journal Entries

random top 40

Weather Forecast for Yellow Point, B.C.

Today

Showers

Showers

11° C

POP - 80%

Tonight

Rain

Rain

9° C

POP - 80%

Wed 14-May

Showers

Showers

13° C 9° C

POP - 70%

Thu 15-May

Mostly Sunny

Mostly Sunny

21° C 12° C

POP - 20%

Fri 16-May

Mostly Sunny

Mostly Sunny

24° C 13° C

POP - 20%

Sat 17-May

Mostly Sunny

Mostly Sunny

23° C 12° C

POP - 20%

Weather data provided by weather.com®

Invalid ImageMaps in XHTML v1.1

Filed in:XHTML
b2evo

Invalid ImageMaps in XHTML v1.1

June 3rd, 2005  · stk

Posting a valid XHTML 1.1 ImageMap -> Hey, What's Going On?

hotspot: clicking takes you to Adidas.com

image

I recently began validating against the XHTML 1.1 standard, rather than the XHTML 1.0 (Strict) standard. There isn't much of a change between the two, so the move wasn't too difficult. However, while checking validation on some old entries, I noticed that image maps yield errors.

I tried fixing the validation problems, but the result was an image map like the one on this page. It validates fine against the 1.1 standard, but doesn't work - either in IE or FireFox. (You can check this with the validation button ... but do it before opening the "Read Full Story" link). Valid XHTML 1.1

EDIT: Since I began serving our pages as the correct MIME type for XHTML v1.1 (i.e., application/xhtml+xml) the image map on this page now WORKS in FireFox. Microsoft doesn't "understand" this MIME type, so the XHTML v1.1 valid image map on this page still doens't work in IE. See the comments for further explanation and this article for further information.

At first, I thought I was coding the thing wrong. Then, I thought that maybe the W3C Validator had a bug. This is the kind of problem that will make you run around and chase your tail!

I couldn't let it lie. (After posting instructions for coding image maps that validate against the XHTML 1.0(strict) standard, I was determined to figure out what was going on.)

- -

XHTML 1.0 (Strict) ImageMap: Invalid in 1.1, but Works

hotspot: clicking takes you to Adidas.com image

The image map on the right is the same one that I posted in the original post. It validates to the XHTML 1.0 (Strict) standard and continues to work in XHTML 1.1, but it doesn't validate. A validation check returns the following three error messages, which you can verify. Valid XHTML 1.1

(1) There is no attribute "name".

(2) Character "#" is not allowed in the value of attribute "usemap".

(3) Non-existent ID "#mapName2".

The Old XHTML 1.0 Strict Code That Works

< map name = "MapName2" id = "MapName2" > < area shape = "rect" coords = "14,123,197,223" href = "http://nike.com" alt = "hotspot"& gt; </area> </map> <img src = "http://www.yoursite.com/imagemap.jpg" style = "width:400px; float:left; border:1px solid #369;" usemap = "#mapName2" alt = "image" />

The higlighted code shows the problem areas. (Note: Though IE works with just id="mapName2", Mozilla-based browsers require name="mapName2". Both are allowed in XHTML 1.0 (Strict) and both are needed for the image map to render properly in both browsers.)

Looking Under the Hood of the DTD

A comparison of the Document Type Declarations (DTDs) shows the changes from version 1.0 (Strict) to version 1.1. (New to DTDs?) If you look at the XHTML 1.0 (Strict) DTD you'll see the following:


<!ELEMENT img EMPTY>
<!ATTLIST img
  %attrs;
  src         %URI;          #REQUIRED
  alt         %Text;         #REQUIRED
  longdesc    %URI;          #IMPLIED
  height      %Length;       #IMPLIED
  width       %Length;       #IMPLIED
  usemap      %URI;          #IMPLIED
  ismap       (ismap)        #IMPLIED
  >
<!ELEMENT map ((%block; | form | %misc;)+ | area+)>
<!ATTLIST map
  %i18n;
  %events;
  id          ID             #REQUIRED
  class       CDATA          #IMPLIED
  style       %StyleSheet;   #IMPLIED
  title       %Text;         #IMPLIED
  name        NMTOKEN        #IMPLIED
  >

In the "img" element, you'll notice that the "usemap" attribute is defined as being a %URI. This means that # (pound sign) can be used, as it specifies a link to a 'fragment identifier' in the current page. (Source: Dan's Web Tips)

For the "map" element, the "id" attribute is required (it MUST be present). This explains why using name="mapName2" alone, will not validate for the FireFox browser in XHTML 1.0 (Strict). Lastly, we see that the "name" attribute is "#IMPLIED" (or optional).

Compare to the XHTML 1.1 DTD, which has been modularized (instead of a single DTD file, there are 4 'core' DTD modules and a number of 'abstract', or optional, modules). The XHTML 1.1 HyperText Core Module is one of the four and the one that contains the attribute definitions for images and client-side image maps. The format of the file is somewhat different, but a similar comparison can be made.


<!-- modify form input attribute definition list
     to allow for client-side image maps
-->
<!ATTLIST %input.qname;
      usemap       IDREF                    #IMPLIED
><!ENTITY % map.attlist  "INCLUDE" >
<![%map.attlist;[
<!ATTLIST %map.qname;
      %XHTML.xmlns.attrib;
      id          ID                       #REQUIRED
      %class.attrib;
      %title.attrib;
      %Core.extra.attrib;
      %I18n.attrib;
      %Events.attrib;
>

Notice how the "usemap" attribute for the "map" element is now an IDREF in the XHTML 1.1 DTD, rather than a URI? This means that this value "must be the same value as the ID attribute of the other element". (Source: James Q. Jacobs) This is why the # yields an error AND why it can't reference the ID as well (since the ID doesn't contain a pound sign).

Also, the "map" element no longer carries the "name" attribute, which we already knew. Just the "id" is used and, as before, it is manditory.

Now that we know the rules, we know WHY the code on the front page (seen below) validates under XHTML 1.1. This made me feel a little better, as it proved that it wasn't a coding error. But why doesn't the bloody thing WORK?

The NEW XHTML 1.1 Code That Doesn't Work


< map id = "MapName2" > < area shape = "rect" coords = "14,123,197,223" href = "http://nike.com" alt = "hotspot"& gt; </area> </map> <img src = "http://www.yoursite.com/imagemap.jpg" style = "width:400px; float:left; border:1px solid #369;" usemap = "mapName2" alt = "image" />

The Bottom Line: It ain't valid, but it works.

It's not a bug in the W3C validator and it isn't that the code is improperly formed.

Browsers just haven't caught up to the 2001 W3C XHTML 1.1 recommendation. (Maybe it just fell through the cracks?) They still DO, however, understand the OLD way, which is why the old code still works. Oddly, IE accepts the newer "id"-only approach, while Mozilla (FireFox) must have the older "name" attribute. (And they call Mozilla a "modern browser" ... bah!)

There's not much of a choice here. If you want an image map that FUNCTIONS, you must write invalid XHTML 1.1 code. This is the ONLY situation that I've come across (so far), where I haven't been able to write valid XHTML code and accomplish what I want. So ... break the standard and feel good about it!

One of these days, after a new browser version release, someone will comment that the first image map is working. Then I'll have a little party, do a little dance, and delete this entry.

(Permalink)
Views: 13863 views
13 Comments · Email Story
Updated: 20-Jan-2006
Web View Count: 13863 viewsLast Web Update: 20-Jan-2006

Your Two Sense:

XHTML tags allowed. URLs & such will be converted to links.


Subscribe to Comments

Auto convert line breaks to <br />

1.flag MKe Comment
06/30/05
Check the website in my profile... someone found some tweak/hack

ok i cheated but hey! it works AND validates ;)

explanations on this page.
2.flag stk Comment
06/30/05
Your "solution" involves creating a custom DocType that changes the "usemap" attribute, to %URI;, from IDREF (among other things).

While XHTML 1.1 provides modularity and custom DTD definitions, one has to ask, "What are you really validating to and is it still 'standard'?"

Answer: Your own DTD and no, not really.

Consider: I could change the name of every tag and every attribute that the W3C puts in the XHTML 1.1 "standard", add a bunch of new tags and attributes that no-one has ever heard of, define all these in a custom DTD and say, "Hey, my page validates to the standard!" (By then though, it's FAR from being "standard")

I'm interested in standards, not about validating. But hey, everybody can make up their own minds on the issue!

Thanks for your comment!

-Scott
3.flag MKe Comment
07/01/05
yes.. i know that's some kind of "cheat" as i said.
And your point makes a lot of sense.

However it's not exactly as if i changed the name "of every tag and every attribute"... this is only some kind of hack about "the ONLY situation that I've come across (so far), where I haven't been able to write valid XHTML code and accomplish what I want".

this allows me to focus on the validy of the rest of the document, and not be always bugged by three annoying little errors.

of course I'd never claim that this *is standard XHTML 1.1* and i can't put the nice little W3C logo :(

anyway you're right : i broke the standards and "feel good about it", while waiting with you for the "new browser version release".
We'll party later.

:-p
4.flag Jamie Comment
07/21/05
Mozilla does *not* require the name attribute to get image maps to work. Specifying xhtml 1.1 AND setting the mime-type to the correct application/xhtml+xml value will give you the results you are looking for. Without the content type, you aren't really using 1.1.

If i right click and view page info on this document in firefox. I see "type" listed as text/html... that is wrong... set this to application/xhtml+xml and you'll really see how things work.

some basic code for you're php site.
5.flag stk Comment
07/21/05
Jamie,

Thanks for writing.

Actually, the content type was set to "text/xhtml+xml" (not "text/html", as you claimed). However, there is no content type "text/xhtml+xml" and it should have been "application/xhtml+xml". Not sure I was thinking there?

Anyway, the change won't have an effect on MSIE (which doesn't support "application/xhtml+xml" ... only "text/html") and I'm currently on vacation and only have access to an IE-enabled machine.

I'll need to test Mozilla and monkey with mime-types a bit more, upon our return.

-Scott

PS - Perhaps I didn't make myself clear. I didn't say that Mozilla needed the "name" attribute in XHTML 1.1, but rather that MSIE uses the id/usemap(w/#) in XHTML 1.0(strict), while Mozilla needs the "name" attribute to work in XHTML 1.0(strict).
6.flag Jamie Comment
07/22/05
thought the code paste would work but it didn't take, check out this link:

http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html

it shows how to set the mime-types using php for those browsers that accept it.
7.flag stk Comment
07/22/05
I also found this article over at HTML Dog.

However, after correctly setting the mime-type to 'application/xhtml+xml', the W3C validator (verbose mode, IE6) reports the content-type as 'text/html'. So ... I wonder if it's really necessary to serve BOTH 'application/xhtml+xml' AND 'text/html', or if those that don't understand 'application/xhtml+xml' simply fall back to what they DO understand, namely 'text/html'?

Thanks for catching the incorrect content-type and posting the link.

I look forward to checking the pages in FireFox to (1) make sure they still work and (2) see the XHTML 1.1 image map code working properly.

-Scott
8.flag stk Comment
09/10/05
Hmmm - Finally am home and have the time to check. The content-type is now correctly set to "application/xhtml+xml" and (in Firefox) the xhtml 1.1-valid image map STILL doesn't work.

(The whole image appears to be a "hotspot", but clicking it doesn't yield the Adidas page).

So ... my original observation still holds ... xhtml-1.1-valid code NO workie in MSIE and FireFox. (But the old ... xhtml-1.0-valid (xhtml-1.1-INVALID) ... code - DOES).

Go figure.

-stk
9.flag HopeSeekr of xMule Comment
11/09/05
Hi!

I had this issue at work, and I effectively solved it. First, you are "cheating" in a manner which is known not to work:



that simply won't cut it. there is no functionality to mimick it. Really you have to use something like PHP to determine whether a browse can support application/xhtml+xml *before* you send them the page. For instance, here is the equiv. PHP code:



Internet Explorer is the only one wherein the
10.flag HopeSeekr of xMule Comment
11/09/05
OK your comment box really fucking sucks, dude... here's the rest of my truncated message, foo

<?php
if (isset($_SERVER['HTTP_ACCEPT']) && (strpos($_SERVER['HTTP_ACCEPT'], "application/xhtml+xml")))
{
header("Content-Type: application/xhtml+xml");
print "\n";
}
else
{
header("Content-Type: text/html; charset=UTF-8");
}
?>

Real-world example: Great concert tickets; right-click, choose page info and see the doc type.
11.flag stk Comment
01/20/06
This is a late reply, HopeSeekr, but I want to say thanks! It was the "before you send them the page" that finally clued me in.

I've since installed a PHP code to serve the correct MIME type "application/xhtml+xml", to those browsers that understand it.

The XHTMLv1.1 image map now functions correctly in FireFox, as a result.

Cheers,
-stk
12.flag Jamie Comment
09/13/06
hah, just happen to run across this site again as I had forgotten the correct way to do the image map! I work on so many projects I couldn't find it in my own source. But, I see you finally are serving up the correct mime-type and things seem to be working smooth in firefox! I actually haven't checked out IE7 yet, but I wonder if it will too accept/require a correct mime-type and display. Cheers!
13.flag stk Comment
09/13/06
Jamie,

Working smooth in FireFox till I forget to close a tag or an &amp; character, then the whole site is effectively DOWN!! (XHTML v1.1 is a tad less forgiving on errors).

It took me a while to clue into the whole XHTML v1.1 and MIME type dealie.

I ended up posting what I learned in this post.

As a result of the imageMap problem with XHTML v1.1, I developed an imageMap enhancement that avoids the image map code condundrum.

Check it out!

Cheers,

-stk