- From: Daniel W. Connolly <connolly@beach.w3.org>
- Date: Tue, 26 Dec 1995 17:49:33 -0500
- To: www-html@w3.org, lynx-dev@ukanaix.cc.ukans.edu
- Cc: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Thanks for passing on the feedback... 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
Received on Tuesday, 26 December 1995 17:50:01 UTC