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

Ian Hickson wrote:
> 
> 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!


That changes in HTML 4.01. From the strict DTD [2]:

 <!ELEMENT MAP - - ((%block;) | AREA)+ -- client-side image map -->

AREA and block content can be mixed. This should have been done in HTML
4.0
but was mistakenly written as [3]:

 <!ELEMENT MAP - - ((%block;)+ | AREA+) -- client-side image map -->


[2] http://www.w3.org/TR/html40/sgml/dtd.html
[3] http://www.w3.org/TR/REC-html40/strict.dtd



> 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.

Not necessarily block level (could be inline). That's an implementation
issue and feedback on your experience is welcome.

> >> 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?

I think that the MAP content should be rendered anyway so that people
who cannot use images will have access to block content. If authors
wish to hide the MAP, they may do so by including it in an OBJECT
element, so that it's only rendered when the image cannot be/is not.
 
> 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.)

Cool! :-)

Based on my comment above, I'd say to render MAP in normal
circumstances (unless hidden by style sheets, inside an OBJECT, etc.).
 
> 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?

I think for backwards compatibility, AREAs should probably not be
rendered.
However, in order to make image maps accessible to users with
disabilities,
user agents should offer a text substitute for image maps. From [4]:


   1.2 Ensure that the user can interact with all active elements in a
       device independent manner. [Priority 1] 
                    For example, ensure that the user can activate links
of a
                    client-side image map in a device-independent manner
(e.g.,
                    by making them available as text links). 

The UAGL Working Group is addressing how this might best be done. I
would
suggest offering the user the option of viewing client side image maps
as a list of
links (literally implemented as <UL>). You might actually use CSS to 
say 'display:list-item' on AREA elements.

[4] http://www.w3.org/WAI/UA/WAI-USERAGENT/

> 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.

So to summarize:

1) Render MAP (unless hidden, in OBJECT, etc.)
2) Don't render AREA (for backwards compatibility)
3) Render block content.
4) Allow the user to choose a text rendering of AREA elements.

Does this hold together?
 
> (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?)

Rich alternative descriptions. You're not bound to an attribute value.
You can include additional links, for example.

Please let me know if this helps since I'm working on the UA guidelines
and will include your solution as techniques if you find that it works!
Thanks for the implementation experience. Also, feel free to
contact me with further questions.

 _ Ian


-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814
Cell:                        +1 917 450-8783

Received on Monday, 25 October 1999 11:00:56 UTC