Re: (Image)Maps in XHTML 2

> Many web authors use image maps. But image maps are only presentational as
> they link *different regions of a picture* to other ressources. So, they are

I wouldn't consider an image map as part of a geographical map system
as purely presentational, even if you could enter latitude and longtitude
instead.

My impression is that the use of image maps for dealing with situations
that weren't intrinsically 2D and graphical was dying out with the 
use of table mosaiced images, instead, so image maps are much more likely
to be used for their real information content than for cosmetics, these
days.  I.E. the use of image maps to implement that sort of navigation
bar described is more or less obsolete.

In any case, this sort of text as images should be done in style languages,
not in purported content.

NB.  In the geographical case, the actual client side image map data is
content.  It could even be very controversial content if it depicts a
disputed border.

After much re-reading.  I think that what you are proposing is:

1) nest the map within the element that embeds the resource that it
   maps;
2) replace shape and coords attributes by a media neutral opaque string.

The overloading of src attributes just confuses things as you are using
an attribute that normally provides a direct relationship to provide an
associative one, and are also using it in a way that involves a redundant
repetition of the image name.  If the correct image is not implied
by containment, you have a problem that, in the general case, the same
image could be present multiple times##.  If you are just using it as
an identifier for the particular element that is replaced by the image,
you  have basically just created an associative equivalent of the 
usemap attribute.

I think your opaque attribute is essentially an ImageRegion attribute,
where image should be stripped of any its connotations of visual
media and simply represents a region in an arbitry n-dimensional 
space (x, y, z, time, pitch, temperature, salinity, sweetness...).

Once you make (2) opaque to the HTML specification, you need yet another
set of specifications to be maintained in the authors' libraries (although
the reality is that most authors will just buy a popular writing XHTML
2.0 book which will re-integrate the specifications, and several others,
to meet the popular understanding of the scope of the term [X]HTML**).

There are plenty of precedents for devolving parts of the specifiction,
e.g. URLs, but one does need to consider that both authors and user
agent developers need to re-integrate the specification, and it
is an unfortunate fact of life that, even with freely downloadable
specifications, even those people who actually have copies of one
core specification rarely retrieve all of the subsidiary ones.
(Especially with paid for specifications, it is common for products
to claim conformance to a specification simply because the upstream
supplier of a component makes the claim, but without the reseller ever
having seen the actual specification - one wonders if the level of
true conformance is any better than for HTML (probably less than 5%!).)

** As can be judged from typical off topic articles, HTML is popularly
understood as meaning a combination of: HTML, CSS, EcmaScript, W3C and
proprietory document object models, proprietory browser automation object
models, URLs, to some extent Flash, to a lesser extent bitmap image formats,
and to a very minor extent HTTP (most authors are in denial of HTTP).

## If the ambiguity represents nesting for fallback purposes, it may be
rather perverse to have the same object as a fallback for itself, but
using the URL to identify the level of the fallback to which the parameter
applies still seems ugly to me, and it also implies that a single element
opening tag may contain multiple instances of your attribute, for use
with the different levels of fallback embedded object.

Received on Thursday, 22 May 2003 02:40:42 UTC