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 <[email protected]>
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
[email protected] 222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================