Like you, I believe we need to cushion people as the Web rolls over to 3.0.
The transition strategy for HTML 2.0 to HTML 3.0 is based on allowing the
server to detect older clients, and avoid sending 3.0 documents to 2.0 clients.
> That said, let me list a few of the advantages of MAPs over FIGs:
> 1. Flexible backwards-compatibility with HTML 2.0-based browsers.
> 2. Ability to reuse maps between multiple images.
> 3. Ability to store maps in files separate from the document, which is
> better for some application which dynamically generate images and maps.
> It also makes maintenance easier for frequently repeated maps.
You can get these benefits without changing HTML 2.0 in any way at all!
All the browser needs to do is to do a GET on the image map file and then
interpret it locally. We already have established formats for these files.
If you want to support older browsers then you are going to have to continue
to provide server side image maps anyway. For new browsers, I think there are
greater benefits from including image map data with the image data itself,
or from using FIG, than with your proposal.
> 4. A browser author can add support for it without the tremendous effort
> involved in correctly supporting all of the other aspects of FIG tags.
The benefits to information providers from text flow, captions, and markup in
alt text far outweigh the modest increase in complexity to browser writers.
> Incidentally, you mentioned that the GIF replacement includes direct support
> for image maps. I've looked back through the past four draft specs for
> PNG/PBF and haven't found any references to this, nor have I seen any recent
> discussions of it on png-list. I'd appreciate it if you could provide a
> pointer to where this issue is being discussed.
I discussed this via email with Thomas Boutell. He replied:
> Incorporating hotlinks, etc. into PBF is a lovely idea, and obviously
> as the author of Mapedit I would enjoy implementing it. I can certainly
> assign a chunk number for it if PBF does in fact become a real format
WebWorld and other work has prevented me from chasing this up more recently.
Perhaps, you can help me to get this into the next draft of PNG.
The advantages of including URL based hypertext links with the image
format are great. It would avoid the need for users to have to deal
with separate image map files as currently needed, and would make it
easy to author with simple image viewing tools. It would also simplify
the case when a server needs to dynamically create an image with hotzones.
The obvious chunk name for this is: "imap" - an abbreviation for IMAGEMAP.
The representation scheme for hypertext links supports a default URL
plus shaped hotzones with rectangles, circles and polygons.
The chunk uses one byte tags to start each link:
Default (0)
Rectangle (1)
Circle (2)
Polygon (3)
This is followed by a null terminated string containing the URL.
After this comes the coordinate data as appropriate to each tag type.
Coordinates are expressed in terms of 2 byte unsigned integers, in
network byte order with x then y. The origin is taken as the upper
left of the image and increases down and to the right (as for image
maps on http servers).
0 points for the default type
2 points for rectangles (upper-left, then lower right)
2 points for circle (centre, then edge point)
N points for n-sided polygons preceded by the number of points
The number of points is expressed as a 2 byte unsigned integer
in network byte order.
Question - should we use 4 byte unsigned integers?
This representation is very easy for browsers to interpret (easier
and more compact than an ASCII notation), as well as being easy
for authoring tools to manipulate. I envisage a viewer with simple
drawing controls for designating hotzones and a single line text
entry field for entering URLs.
-- Dave Raggett <dsr@w3.org> tel: +44 117 922 8046 fax: +44 117 922 8924
Hewlett Packard Laboratories, Filton Road, Bristol BS12 6QZ, United Kingdom