Re: Implementation Query: <MAP> with mixed <AREA> <A> !?

On Mon, 25 Oct 1999, Ian Jacobs wrote:
>> When trying to implement client side image maps in Mozilla, we have
>> hit a problem.
>> 
>> The following is valid XHTML:
>> 
>>    <p><img src="x" alt="text" usemap="#map" /></p>
>>    <map id="map">
>>       <p><a href="#a" shape="rect" coords="10,10,20,20">A</a></p>
>>       <area href="#b" shape="rect" coords="30,30,40,40" alt="B"/>
>>    </map>
>> 
>> But, assuming images are disabled or the UA does not support
>> images, how should the above be rendered?
> 
> I suggest the following:
> 
> 1) Render the content as you would outside of a MAP. 
> 2) Convert the AREA to an A element whose link text is value of the
>    the *mandatory* "alt" attribute.

But the A element is not legal where the AREA element is! AREA is only
allowed at the %block; level inside MAP elements, whereas A is only
allowed _inside_ elements that are %block; level.

Do you mean that each AREA element should be turned into a block level
link? IMHO this would probably look very ugly.


>> I need to know what the expected behaviour as we are currently
>> trying to implement this in Mozilla.
> 
> The expected behavior in HTML 4.01 is to render body content. From [1]:
> 
> <BLOCKQUOTE>
>    The MAP element content model allows authors to combine the
>    following:
>    1. One or more AREA elements. These elements have no content
>       but specify the geometric regions of the image map and the
>       link associated with > each region. Note that user agents do
>       not generally render AREA elements. Therefore, authors must
>       provide alternate text for each AREA > with the alt attribute
>       (see below for information on how to specify > alternate
>       text).
>    2. Block-level content. This content should include A elements
>       that specify the geometric regions of the image map and the
>       link associated with each region. Note that the user agent may
>       render block-level content of a MAP element. Authors should
>       use this method to create more accessible documents.
> </BLOCKQUOTE>
> For bullet two, the HTML WG decided to change "may" to "should" (for
> the rendering part) after the document became a Proposed
> Recommendation. This change will appear in subsequent drafts.
 
So, what should be rendered where the broken IMG element stands? The
IMG's alt text? And should that IMG act as a link? A link to what?

If an IMG element refers to a MAP element, we currently render the IMG
element and give it the areas that the MAP element requests. We also
render the MAP element. 

Should we be making MAP elements 'display:none' when the IMG USEMAP
element has displayed the image map? Or should the MAP be displayed
anyway?

If the MAP should be only be displayed if the IMG element is broken,
then how do we express this in CSS? (We are using an entirely
CSS-based rendering engine.)

If the MAP should always be displayed anyway, should that include the
AREA elements? Or should the AREA elements only be displayed if the
IMG is broken, although the rest of the MAP is always displayed?

If the AREA elements are always displayed when the MAP is displayed,
then thankfully we can do this easily:
 
   AREA:before { content: attr(alt); }

...however if this has got to be dependent on the IMG element's state
(image displayed or not) then we will have great difficulty
implementing this.

If the MAP is always displayed and AREA elements are always displayed
as well, then we will be breaking thousands of pages on the net
already, as currently MAP elements with only AREA elements inside are
not rendered at all.

(BTW, could you explain why AREA and %block; being allowed as mixed
content in the MAP element helps accessibility in any way? What does
this allow that the previous content model did not?)

Thanks for your help so far,
-- 
Ian Hickson
"I take a Professor Bullett approach to my answers. There's a high
probability that they may be right."
  -- Dr Snow; Mechanics Lecturer at Bath University; 1999-03-04

Received on Monday, 25 October 1999 10:10:12 UTC