In message <01HZ9PNV9LG20011DO@SCI.WFBR.EDU>, Foteos Macrides writes:
>
> The essence of the criticisms concerns the elimination of the
>IMAGEMAP attribute for the FIG element, so that it becomes simply a
>block-created "encasement" for INSERT, which in turn uses the MAP element
>for handling client-side imagemaps. There is a presently bad link in the
>INSERT draft for the client-side imagemap draft:
>
>http://www.ics.uci.edu/pub/ietf/html/draft-ietf-html-clientsideimagemap-01.txt
>
>which perhaps is going to be a copy or rename of:
>
> http://www.ics.uci.edu/pub/ietf/html/draft-seidman-clientsideimagemap-01.txt
Actually, ietf-html-clientsideimagemap is older than deidman-clientsideimagemap.
It was never an HTML WG work item. The first draft was mis-named. It
was a spyglass technology that has since been implemented by Netscape and Microsoft.
At this point, that makes it a good candidate for standardization.
> It it certainly better to add a new INSERT container element than
>to make EMBED a container and then need to grapple with Netscape's empty
>EMBED, but by the same token, if draft-ietf-html-clientsideimagemap-01.txt
>is actually draft-seidman-clientsideimagemap-01.txt, why not instead use
>a replacement for MAP which in turn uses a container replacement for SHAPE?
As I recall, Spyglass raised some issues with the backwards-compatibility
of such a design. I never studied the details well enough to understand it.
I invite folks to submit examples/test cases (to www-html@w3.org) that
illustrate the merits and problems of the various designs. This will
allow those of us drafting the document to have a focused discussion
of the technical issues.
Complete documents, please. Bonus points for validated documents with
proposed DTDs.
Dan