W3C home > Mailing lists > Public > public-html@w3.org > August 2008

Using usemap for purposes other than image maps, and related questions

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 28 Aug 2008 10:20:55 +0000 (UTC)
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>, Ben Boyle <benjamins.boyle@gmail.com>
Cc: public-html <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0808280436190.14795@hixie.dreamhostps.com>

On Sun, 26 Aug 2007, Lachlan Hunt wrote:
> Another approach [for marking up comic strips] described by Joe Clark is 
> to use an image map, with the alt text for each region provided by an 
> <area> element [4].  However, I couldn't find any real world sites that 
> use this technique.
> [4] http://joeclark.org/book/sashay/serialization/Chapter06.html#h2-4240
> However, there's currently an issue with the spec which would affect the 
> use of the image map technique.  The spec currently states:
> > However, if the area element has no href attribute, then the area 
> > represented by the element cannot be selected, and the alt attribute 
> > must be omitted.
> According to that requirement, using the image map would be 
> non-conforming because the areas would not need to be hyperlinks and so 
> they would need to use alt attributes without href attributes. 
> Therefore, I think that's a mistake in the spec and that requirement 
> should be removed.

The point of image maps is to make a list of links which, when presented 
visually, are presented in the context of an image. Marking up a comic is 
really not a use case that <map> and <area> are intended for, and I don't 
really think it makes sense to use those same elements for two such 
unrelated use cases.

On Wed, 5 Sep 2007, Ben Boyle wrote:
> area without @href
> This is defined as a "dead area" but I think it is useful, similar to "a 
> placeholder for where a link might otherwise have been placed". I'd like 
> these two concepts treated in a consistent fashion, and I prefer the 
> approach described for "placeholder links".
> A simple use case: using <area> to mark a point or region on a map 
> (defined by the @alt value) - there may not always be a relevant link 
> (perhaps this is a semantic change to the meaning of "image maps"). 
> Mandating the link is likely to lead to oddities such as self 
> referencing links or linking to the map fragment itself (using 
> #<map-id>).

I don't really understand. <area> without href="" is allowed.

> area/@alt (continuing from above, when there is no @href)
> "However, if the area element has no href attribute, then the area 
> represented by the element cannot be selected, and the alt attribute 
> must be omitted."
> I challenge the assertion "cannot be selected". This is a reflection of 
> current UAs if anything, not a necessity of the HTML language. I see 
> three options:
> 1. Do nothing (spec remains tainted by UA behaviour).
> 2. Change the statement into an instruction for UAs. That is, we require 
> UAs to implement this behaviour. I would change the "cannot" into a 
> "must not" for a start, then edit for grammar.
> 3. Instruct UAs to make these elements able to be selected (i.e. make 
> them accessible). Define how this is to be accomplished.
> I vote for making area accessible (regardless of @href). This may relate 
> to work done by ARIA or similar initiatives? It also is a better fit to 
> me. The @href attribute can be manipulated through the DOM, it's better 
> to have the element always accessible rather than have accessibility 
> being toggled. Naturally you can't "activate" (if that is the right 
> term) an area without @href.
> As I said at the beginning, I think this is very similar to "placeholder 
> links" and I'd like similar treatment.

You can't select an <a> element without an href="", why would you be able 
to select an <area> without an href=""? I don't understand.

> area/@shape
> Why poly/rect and not polygon/rectangle? I think it would be better to 
> support real words rather than abbreviations. It's bad enough that HTML 
> is defined in US english without bringing arbitrary abbreviations into 
> the mix. UAs could easily parse this value on the first 4 characters.

The keywords are from HTML4.

> It is somewhat confusing untangling the meaning of shape="default" 
> (entire image map) vs the "missing value default" (assumes "rect"). I 
> suggest the wording of this section be carefully reviewed. I suggest 
> this sentence include an explanation of the "default" shape, like so: 
> "In the default state state, area elements must not have a coords 
> attribute. The 'default' shape exactly matches the entire image map."

Technically this is defined in the next section, but I agree it would be 
helpful to repeat the information near the author-related stuff, so I've 
added it.

> Maybe the table (used for all enumerated attributes?) could be designed 
> to include the "missing value default" in there.

I'm not really sure how that would work. I don't think it'd be simpler.

> Curiosities with @shape="default"
> What does this mean?
> <a href="img.html"><img usemap="foo" ... alt="Image" /></a>
> <map id="foo">
> <area shape="default" alt="Map" href="map.html" />
> ...
> </map>
> Which @alt and @href apply?

The image would say "Image" and if selected would display an image map 
with one option, "Map", linking to "map.html". Assuming default CSS, there 
would be some space just below the image that linked to "img.html".

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 28 August 2008 10:21:06 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:37 UTC