14601 2011-10-30 20:57:19 +0000 Investigate if support for <a> inside image maps should be brought back to HTML 2011-11-02 21:17:00 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified PC Linux RESOLVED WONTFIX P2 normal --- 1 bugs ian bzbarsky ian mike Ms2ger public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 59242 0 bugs 2011-10-30 20:57:19 +0000 http://www.whatwg.org/specs/web-apps/current-work/#the-map-element has an example where <map> contains both <a> and <area> elements. That would become significantly simpler if image maps could handle anchor elements similarly (perhaps not exactly the same way) as in HTML4. I was actually writing a gecko patch to remove support for <a> in image maps, but had all the time the feeling that I'm removing something useful and decided to not to remove the support after all - at least not right now. The difference to HTML4 could be that area/a element handling could be simplified. All the area and a elements underneath map could be taken account. Or something like that. Whatever is most backward compatible (I don't feel really strong about this issue, but seems like the issue wasn't ever discussed properly.) 59364 1 ian 2011-11-01 05:54:45 +0000 It was discussed in quite a lot of depth and based on solid numbers from one of the Google crawls a few years ago. How would you like it to be investigated further? 59386 2 bugs 2011-11-01 12:03:57 +0000 (In reply to comment #1) > It was discussed in quite a lot of depth I wish I could find where it was discussed, and what were the arguments. > and based on solid numbers from one of > the Google crawls a few years ago. that is not important. HTML spec adds also new (IMO less useful) stuff which isn't used anywhere. <a> in a map is just an HTML4 feature not implemented widely. It could be implemented properly everywhere. I was also thinking to use image map for <canvas>, but apparently that approach hasn't gain support when discussing how to handle a11y for canvas. I don't know yet why. 59387 3 bugs 2011-11-01 12:05:09 +0000 I'll ask around and try to search some reasoning for both dropping support for <a> and not supporting image map in canvas. 59390 4 bugs 2011-11-01 13:34:16 +0000 I found http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-April/003508.html But nothing there indicates that there was an agreement to drop support for <a>. Searching some more... 59410 5 ian 2011-11-01 16:27:48 +0000 Decisions are not based on consensus, so I wouldn't look for an agreement. Here's the lay out of the land regarding using <a> for image maps: - it's not supported by many browsers - it's used by very few authors - it provides functionality redundant with <area>, which is widely supported and widely used - it is positioned to allow for better fallback, but does not, since <area> is required to be supported by all user agents, including those that don't do graphical image maps. - it has a commensurate cost for implementations, testing, tutorials, and speccing. - it has an additional cost due to the introduction of the possibility that an <a> element will be focused but that the focus won't be on the page where the <a> element is displayed, but will instead be where the image map is (with <area> elements, they can _only_ be focused in the image map, so it's not as huge a deal). It's true that sometimes you will want to use both <a> and <area> for the same link. In fact, there are many more times where you'll want to use <a> twice for the same link, or <a> and <link>. This in itself is not a reason to require that the same element be used for both. Consider, in particular, the example in the <map> section in the spec. It is equivalent to a page with this structure: <HEADER> <H1>Toys</H1> <A HREF="/clothes/">Clothes</A> <A HREF="/toys/">Toys</A> <A HREF="/food/">Food</A> <A HREF="/books/">Books</A> </HEADER> ... <FOOTER> <A HREF="/clothes/">Clothes</A> <A HREF="/toys/">Toys</A> <A HREF="/food/">Food</A> <A HREF="/books/">Books</A> </FOOTER> The only difference is that the first set of links is actually done as an image, so it needs an image map, and so the <AREA> elements have to be put somewhere. Since the page has these links twice, a simple place to put the links is at the bottom. It's not like they're the same link, though. It's quite possible, in fact, that the page would look like this: <HEADER> <H1>Toys</H1> <A HREF="/clothes/#top">Clothes</A> <A HREF="/toys/#top">Toys</A> <A HREF="/food/#top">Food</A> <A HREF="/books/#top">Books</A> </HEADER> ... <FOOTER> <A HREF="/clothes/#bottom">Clothes</A> <A HREF="/toys/#bottom">Toys</A> <A HREF="/food/#bottom">Food</A> <A HREF="/books/#bottom">Books</A> </FOOTER> An author would still need somewhere to put the image map links, and might still put them with the other links. But it doesn't argue for reusing the same <A> element for two links. 59527 6 ian 2011-11-02 20:53:14 +0000 Based on comment 5 and further thought on the topic, I come to the same conclusion that I did before: removing this subfeature of <a> is a net win. 59531 7 bugs 2011-11-02 21:17:00 +0000 Ok. I disagree, but I don't care enough about the issue to reopen this bug.