Home › Blog

Image Map & HTML5

Wed, Apr 6, 2011 9:57 pm — wasabi

Minefield logo

As a part of the DPS909 course, students were asked to work on Firefox bug #565031. This bug has to do with whether or not different kinds of white space characters should be treated as separators in an image map’s coords attribute. Well, it sounds really trivial — so trivial that fixing it simply isn’t a good use of a developer’s time. Therefore, this is a perfect opportunity for students to take a stab at.

I started to work on this bug by looking at the behaviours of various browsers that I had easy access to, and ran them on Mac OS X 10.6.7. The ones tested include:

  • Safari 5.0.4
  • Goole Chrome 10.0.648.204
  • Firefox 4.0
  • Firefox 2.0.0.20

Blow is the test code that I used:

  1. <!DOCTYPE html>
  2. <html>
  3. <body>
  4. <img src="http://www.bradchen.com/sites/default/files/firefox.gif" usemap="#map" width="250" height="250" />
  5. <map name="map">
  6. <area shape="rect" coords="
  7.   11  
  8.   18  
  9.   149 
  10.   107
  11.   " href="http://www.mozilla.org/" />
  12. </map>
  13. </body>
  14. </html>

As you can see, the coords property has new line and tab characters. As per the HTML5 spec, this image map should not work. However, all of the browsers tested can handle such usage correctly. This is tested by loading the page and press the tab key to see the outline of the image map, as shown below:

Image Map Bug on Firefox 2

What’s more interesting is that, WebKit-based browsers, namely Safari and Google Chrome, even expand the standard quite a bit, and are willing to correctly work with the following:

  1. <area shape="rect" coords="dfakjs
  2.   11fdafasdfsad18  dfjlkas
  3.   fdskjfjasklf149 
  4.   107dkjafsajfklsad
  5.   " href="http://www.mozilla.org/" />

Now, it seems that supporting non-standard characters isn’t, after all, a bad thing. Also, according to HTML5 for Web Designers by Jeremy Keith, HTML5 standard aims to be as much backward-compatible as possible. For example, HTML5 includes deprecated HTML elements in its specification. As such, it seems counter-intuitive that HTML5 spec suddenly refuses to treat non-0×0020 white space characters as number separators.

Anyway, in order to fulfill the assignment, I cloned mozilla-central, made changes to nsImageMap.cpp as suggested in the ticket, and tried to build Minefield (a HUGE pain in the neck). The changes I have made are below:

  1. diff r e6b318aca788 layout/generic/nsImageMap.cpp
  2. -- a/layout/generic/nsImageMap.cpp	Wed Apr 06 17:38:21 2011 0700
  3. +++ b/layout/generic/nsImageMap.cpp	Wed Apr 06 23:10:53 2011 -0400
  4. @@ -112,12 112,7 <code></code>
  5.  inline PRBool
  6.  is_space(char c)
  7.  {
  8.   return (c  ' ' ||
  9. -          c  '\f' ||
  10. -          c  '\n' ||
  11. -          c  '\r' ||
  12. -          c  '\t' ||
  13. -          c  '\v');
  14.   return c == ' ';
  15.  }
  16.  
  17.  static void logMessage(nsIContent*      aContent,

This change now prevents Minefield to work with non-0×0020 spaces. Though, this patch is not yet complete. As suggested by khuey in the ticket, nsImageMap.cpp should make use of nsContentUtils::IsHTMLWhitespace, and therefore nsContentUtils::IsHTMLWhitespace needs to be updated as well. Doing so requires more research into the HTML5 specification, in order to ensure that it will make Firefox compliant with the specs around white spaces of other uses.

Again, due to ensuring backward compatibility, I’m inclined to either leave the bug unfixed or ask WHATWG to change HTML5’s spec.