Re: 12-21-95 INSERT draft

"Daniel W. Connolly" <connolly@beach.w3.org> wrote:
>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-clientsideimage
>map.
>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.

	Whatever the background w.r.t. WG work items, there is an IETF
Working-Draft by James L Seidmam of Spyglass, Inc., dated August 8, 1995,
which is what Netscape and Microsoft also implemented in their clients,
and the recent INSERT draft would make sense if the IMG attribute
extension and the MAP and AREA elements described via text and defined
via a DTD in that draft, were adopted in conjunction with the new INSERT
and ALIAS elements, and a "strip-down" of the "HTML 3.0" FIG element.

>>	It is 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.

	The MAP element is a "non-displayed" NAMEed reference:
	
   <MAP NAME="name">
   <AREA [SHAPE="shape"] COORDS="x,y,..." [HREF="reference"]
         [NOHREF] [ALT="alt"]>
   </MAP>

and depends on the USEMAP attribute extension for IMG, e.g.:

	<IMG SRC="picture.jpg" USEMAP="#name">

It is "old-fashioned" w.r.t. HTML 3.0 principles that would use ID instead
of NAME, plus other "general" attributes.  But more importantly (I'm not
sure if this is more appropriately referred to as a "forwards-compatibility"
rather than "backwards-compatibility" problem), if AREA or some other-named
element were made a container, a client not aware of MAP or container
elements within it would display the content, in effect, as "garbage".
It's the same problem as with the STYLE container versus a LINK for
specifying style sheets.  But conversely, you are left with need for
an informationally impoverished and too-often not used ALT attribute,
which wouldn't be handled, even if present, by any clients as yet
ignorant of MAP and AREA.

	This contrasts with the FIG strategy for client-side image maps:
	
   Company home page:
<FIG SRC="mainmenu.gif">
 <H1>Access HP from Hewlett Packard</H1>
 <P>Select between:
 <UL>
  <LI><A HREF="guide.html" SHAPE="rect 30,200,60,16">Access Guide</A>
  <LI><A HREF="about.html" SHAPE="rect 100,200,50,16">About HP</A>
  <LI><A HREF="guide.html" SHAPE="rect 160,200,30,16">News</A>
  <LI><A HREF="guide.html" SHAPE="rect 200,200,50,16">Products</A>
  <LI><A HREF="guide.html" SHAPE="rect 260,200,80,16">Worldwide Contacts</A>
 </UL>
</FIG>

Though a FIGnorant GUI-client will not have the benefit of an actual
image map, every client in existence is able to access all of the
actual "information" being offered via that markup, and anyone, no
matter how new to the WWW and HTML, who has grasped the basic concept
of an image map, could generate and offer "universally informational"
markup of that sort.


>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.

	OK, but do keep in mind the this is not a situation of wondering
whether a falling tree makes a sound if there's nobody in the forest to
hear it.  There *are* clients which consistenly have taken the W3C
standardization process seriously, have always fully accepted the premise
that HTML is a form of SGML, not simply an element and attribute soup for
markup geared to "application library functions" (motif, windows, or
whatever 8-), and have heavily based their development during this past
year on the now, much too long expired HTML 3.0 draft.  The DTD for FIG
and for the SHAPE attribute of A, though expired, already exists therein.
The INSERT draft does need an element or additional attributes to indicate
whether the markup should be handled as a block or as "character level"
markup, and if a block, how to handle positioning and text flow.  But
markup as beautifully crafted as FIG should not be "stripped-down" for
that purpose, unless an equally effective alternative is developed.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Thursday, 28 December 1995 13:39:05 UTC