- From: Ian Hickson <py8ieh@bath.ac.uk>
- Date: Mon, 25 Oct 1999 23:13:31 +0100 (BST)
- To: Ian Jacobs <ij@w3.org>
- cc: www-html-editor@w3.org, Dave Raggett <dsr@w3.org>, lehors@w3.org, www-html@w3.org
On Mon, 25 Oct 1999, Ian Jacobs wrote: >>>> <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> >>>> >>>> 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 *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 --> I am aware of the change, this is why I am asking about this in the first place. ;-) The problem that the A element is not legal where the AREA element is new to HTML 4.01. This: <!ELEMENT MAP - - ((%block;) | AREA)+ -- client-side image map --> ...means that %block; level elements and AREA elements may be mixed, and not that AREA elements can be put inside %block; elements. Thus this: <map> <p><a></a></p> <area/> <p><a></a></p> </map> ...is valid, but this: <map> <p><a></a> <area/> </p> </map> ...is not. >> 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). Not using the current content model, since even if AREA is styled as "display:inline" all surrounding content will be "display:block" and so an anonymous block will automatically wrap around the AREA 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. Ok, I agree with this. (So long as the MAP element contains %block; level markup, anyway.) 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? And should the AREA elements in the MAP be included where the IMG element was, or as part of the MAP element? i.e., imagine this markup: <p>Select your destination:</p> <p><img src="broken" alt="A, B, C, or D?" usemap="#map" /></p> <p>Thank you.</p> <map id="map"> <area href="a" shape="rect" coords="00,00,10,10" alt="A"/> <area href="b" shape="rect" coords="10,00,20,10" alt="B"/> <area href="c" shape="rect" coords="00,10,10,20" alt="C"/> <area href="d" shape="rect" coords="10,10,20,20" alt="D"/> </map> How should this be rendered? Here is a possibility: Select your destination: * A * B * C * D Thank you. Here is another (a lot easier to implement): Select your destination: A, B, C, or D? Thank you. * A * B * C * D Or (clicking on the question brings up a menu with items A B C and D): Select your destination: A, B, C, or D? Thank you. Which is what was intended? Or is it something else again? >> 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. And in practical terms, this means we do what? Do we say "AREA {display:none}" or "AREA:after {content: attr(alt)}"? Or do we do the first if the image map's image is displayed and the second if it is not? (Quite difficult.) > 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? 1-3 are no problem, and we already do them. 4 is technically also possible (by modifying the UA stylesheet). But the above does not cater for the case where the image is missing and the image map uses AREA elements. Exactly what should we do in this case? (See above.) >> 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. Yes, allowing %block; content in MAP allows this, since you can use A elements for the map shapes (using coords and shape). But why allow AREA elements to be mixed with block level elements? Does AREA add anything that the A element cannot already do? Cheers, -- 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 18:13:35 UTC