12-21-95 INSERT draft

Foteos Macrides (MACRIDES@sci.wfbr.edu)
Tue, 26 Dec 1995 16:26:06 -0500 (EST)


Date: Tue, 26 Dec 1995 16:26:06 -0500 (EST)
From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Subject: 12-21-95 INSERT draft
To: www-html@w3.org, lynx-dev@ukanaix.cc.ukans.edu
Message-Id: <01HZ9PNV9LG20011DO@SCI.WFBR.EDU>

	I've returned from the Christmas holidays to find my mail box flooded
with messages from disappointed Lynx users concerning the recent W3C draft on
INSERT:

                  Inserting multimedia objects into HTML3
                                      
                        W3C Working Draft 21-Dec-95
                                      
   This version:
          http://www.w3.org/pub/WWW/TR/WD-insert-951221.html
          
   Latest version:
          http://www.w3.org/pub/WWW/TR/WD-insert.html
          
   Editor:
          Dave Raggett <dsr@w3.org>
          
   Authors:
          Charlie Kindel, Microsoft Corporation
          Lou Montulli, Netscape Communications Corp.
          Eric Sink, Spyglass Inc.
          Wayne Gramlich, Sun Microsystems
          Jonathan Hirschman, Pathfinder
          Tim Berners-Lee, W3C
          Dan Connolly, W3C
          
     _________________________________________________________________
                                      
	I am cross-posting this to the www-html and lynx-dev lists,
and request that Lynx users and other concerned persons continue the
discussion via those lists and/or the authors of the INSERT draft, not
via private email to me (I just work on Lynx as a hobby, and have nothing
to do with either the development of W3C standards or of element and
attribute soups. 8-).

	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

If so, that draft defines MAP as an element which contains empty SHAPE
elements that *OPTIONALLY* may have an ALT for use by non-GUI clients,
or by GUI-clients with image processing turned off, in contrast to the
FIG IMAGEMAP model which forces (or at least strongly promotes) inclusion
of alternate text for creating appropriate links (to be used as if regions
of a map had been "clicked").

	I suspect UniWWW client users similarly may be feeling disappointed
by this particular aspect to the INSERT draft.  That client also based it's
development primarily on the March 1995 HTML 3.0 draft, such that the
elimination of FIG's IMAGEMAP attribute and use of MAPs with empty SHAPE
elements and purely optional ALTs amounts to a "crippling" of FIG and
abandonment of an ideal.

	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?

				Fote

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