s/the issue/the issues

I started doing this, but I couldn't come up with a realistic example, because I couldn't work out when you would actually want to do this.

If images are enabled, then users would presumably just use the image map (and <area> elements).

If images are disabled, then users would just be faced with the image map in list form, generated from the <area> elements.

So when do they get exposed to the markup with <a> elements?

Sorry, I feel I'm just forgetting something today. Could someone explain how the <a><area> thing would actually be used? Is it for cases where a user would want to see both a textual version and the image map version? And if so, why would a user ever want that?

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: I'm happy to add an example. I just can't work out what a realistic one would be.

cc'ing Anne, since he was the one who said he liked being able to do <a><area> in 2005 -- can you remind me why we might use this?

Back then it seemed like <area> was kind of meaningless fallback as it would not display in contemporary user agents. However, that is just poor implementation and not a reason to make markup more complicated.

(In reply to comment #2)
> If images are disabled, then users would just be faced with the image map in
> list form, generated from the <area> elements.

While Lynx/Elink/Links present an image map as a collapsed list, GUI browsers where the image is unavailable, do not work like that.
 
> So when do they get exposed to the markup with <a> elements?

After some testing & thinking:

1 General: when using an UA which doesn't present image map in
  list form. Fore eample, when using Elinks, and
  @alt=<space-character>, then the image map isn't presented 
  as collapsed image map list  
2 when the <map> is inside (or outside) <object> and/or the
  UA or AT doesn't support image maps in combination with 
  <object> (Elinks, Links, Webkit, partly IE).
3 when the intention is to present the links both as image map
  and as "normal" links. E.g. a navigational header with an image
  map - and the navigation links repeated at bottom of page.
4 with reference to comment #4: when UA doesn't support the needed 
  CSS level or the author failed to make the <area> visible via 
  area::before { content:attr(alt);}
  or when AT doesn't support generated content (even AT which
  support generated content [VoiceOver] seems to choke when
  working with generated content compared with normal conent.
5 when the usemap img has role=img: role=img does not cover 
  whether @longdesc nor @usemap. Thus, when using @usemap
  one must, at least in VoiceOver, manually set the role
  to "img", or else it won't read the @alt text of the <img>.
  (For accuracty: it could work to skip the anchor element and
  instead rely on making <area> visible via CSS)
 
> Sorry, I feel I'm just forgetting something today. Could someone explain how
> the <a><area> thing would actually be used? Is it for cases where a user would
> want to see both a textual version and the image map version? And if so, why
> would a user ever want that?

I hope the above helps.

(In reply to comment #2)
> If images are disabled, then users would just be faced with the image map in
> list form, generated from the <area> elements.

While Lynx/Elink/Links present an image map as a collapsed list, GUI browsers where the image is unavailable, do not work like that.
 
> So when do they get exposed to the markup with <a> elements?

After some testing & thinking:

1 General: when using an UA which doesn't present image map in
  list form. Fore eample, when using Elinks, and
  @alt=<space-character>, then the image map isn't presented 
  as collapsed image map list  
2 when the <map> is inside (or outside) <object> and/or the
  UA or AT doesn't support image maps in combination with 
  <object> (Elinks, Links, Webkit, partly IE).
3 when the intention is to present the links both as image map
  and as "normal" links. E.g. a navigational header with an image
  map - and the navigation links repeated at bottom of page.
4 with reference to comment #4: when UA doesn't support the needed 
  CSS level or the author failed to make the <area> visible via 
  area::before { content:attr(alt);}
  or when AT doesn't support generated content (even AT which
  support generated content [VoiceOver] seems to choke when
  working with generated content compared with normal conent.
5 when the usemap img has role=img: role=img does not cover 
  whether @longdesc nor @usemap. Thus, when using @usemap
  one must, at least in VoiceOver, manually set the role
  to "img", or else it won't read the @alt text of the <img>.
  (For accuracty: it could work to skip the anchor element and
  instead rely on making <area> visible via CSS)
 
> Sorry, I feel I'm just forgetting something today. Could someone explain how
> the <a><area> thing would actually be used? Is it for cases where a user would
> want to see both a textual version and the image map version? And if so, why
> would a user ever want that?

I hope the above helps.

FWIW, http://www.blocket.se/ is an example of having both an image map and a list of links. (Some users prefer to click on the map while others prefer to click on a link in the list.)

(In reply to comment #4)
> Back then it seemed like <area> was kind of meaningless fallback as it would
> not display in contemporary user agents. However, that is just poor
> implementation and not a reason to make markup more complicated.

The poor implementation is, in the eyes of many of us, is the lack of support for <a @coords @shape>link</a> in HTML5. When you suggest that one may use area:link::before {content:attr(alt)} instead, they you are really suggesting to the very same thing - except that a fully CSS based solution is less robust.

Nevertheless, using CSS that way, is of course an excellent tip.

 And in Webkit, on can do pretty cool things with that effect: If you tabulate from visible area link to visibla area link, Webkit will highlight both the visible text link as well as the area on the image. Pretty cool, and with many many potenial use cases.

(In reply to comment #6)
> 
> While Lynx/Elink/Links present an image map as a collapsed list, GUI browsers
> where the image is unavailable, do not work like that.

Please file bugs with those browsers then.


I'll provide an example of a redundant image map, though, as suggested above.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.

Checked in as WHATWG revision r5572.
Check-in comment: image map example
http://html5.org/tools/web-apps-tracker?from=5571&to=5572

(In reply to comment #10)

Thank you for adding the example. It is quite close to what I had in mind. But for one detail: 

the spec text uses the phrase  "to ease maintenance". However, to really ease maintainance, I would have wrapped each anchor element around each corresponding <area> element, as this  would make se even clearer what belongs together.

Since the <area> element is not considered interactive in HTML5. there should be no problem in doing so, no? I am, in particular, interested in avoding to have to repeat the text of the anchor element inside the area element - that's a further simplification of the maintainance.

<map name=map ><!--no alt here-->
  <a href="link"><area href=link coords="0,0,10,10" shape=rect >Lorem ipsum</a>
 </map>

In HTML4, this was in theory not an issue: the <map> could contain both <area> and <a> but UAs would ignore the one or the other. Consider,  text based web browsers: they treat an image map as an interactive list of links. We should avoid that they get a double set of of links. 

From HTML4, section "13.6 Image maps"

]] When a MAP element contains mixed content (both AREA elements and block-level content), user agents must ignore the AREA elements.

Authors should specify an image maps's geometry completely with AREA elements, or completely with A elements, or completely with both if content is mixed. Authors may wish to mix content so that older user agents will handle map geometries specified by AREA elements and new user agents will take advantage of richer block content.
[[

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Whether it's inside or adjacent doesn't seem to materially affect how easy this is to maintain. I don't mind using the other style if we have reason to include another example, but at this point this seems like bikeshedding on an example.

mass-moved component to LC1