Re: HTML 4.0 review

There are two further issues that I would like to raise at this point:

1. The relationship between LONGDESC and the metadata approach which Al
has been patiently and consistently advocating for the past few months.
Conceptually, of course, the two solutions are not mutually exclusive: it
would be possible to make available both a LONGDESC attribute and an HTTP
mechanism, each of which would be in itself capable of correlating an
image with a long description. In practice, I wonder to what extent a move
in favour of the LONGDESC attribute, assuming that it were to be adopted
by HTML user agents, authoring tools and content providers, together with
increasing acceptance of OBJECT, would preclude the widespread adoption of
a metadata framework, perhaps even rendering it unnecessary. The impact of
LONGDESC on metadata is another imponderable which falls for consideration
in determining the merits of the proposed LONGDESC attribute. I am not
acquainted with the details of the metadata approach and do not know how
far it is from being widely available. Based on limited evidence I would
tend to support LONGDESC as a regrettable necessity, but this is of course
open to argument.

2. A few corrections need to be made to what I earlier said regarding
frames. The value of NAME is not an URL fragment; TARGET is a separate
concept which allows a document or other resource, designated by an URL,
to be loaded into a particular frame. Nevertheless, the general point is
still valid: NAME is not really intended as a title that can be presented
to the user, even though, as Lynx 2.7.1 demonstrates, it can be coopted
for this purpose. Furthermore, the example of frames which is given in the
HTML 4.0 draft highlights the fact that the resource referred to by SRC
can be an image, in which case, there is no provision for ALT text, let
alone a long description. In the absence of a metadata framework, it would
appear that modification of the FRAME element is necessary. Frames can be
nested, thereby realising quite complex visual structures, and the content
of any frame can be changed whenever a link is activated. How can such
functionality be conveniently transported into the braille or audio media? 
How should an audio user agent render frames, and what implications does
this have for markup considerations? Can it be said a priori that it would
be best if each frame were labeled with a descriptive title, as proposed
in my earlier message?

Received on Saturday, 13 September 1997 02:49:25 UTC