Re: IMG ALT attribute in HTML 4.0

"Rob" <wlkngowl@unix.asb.com>:
> > I don't think it's a good idea. I think ``IMPLIED'' is a sufficient
> > condition as before because ALT means altenate text as you wrote
> > above. If there are no ALT attributes in <IMG>, user agents can know
> > there need not any alternate text for this image and it's sufficient.
> > But new HTML 4.0 draft botheres HTML authors those who decide
> > alternate text is not necessary to some images (e.g. images for
> > decoration) to fill with NULL text in ALT attribute.
> 
> So use something like <IMG SRC="border.gif" ALT="Decorative Border">
> to let users know the image is decorative. Since the image is purely 
> decorative, in the future it can be defined using style sheets

I don't think so because what style sheets supply are different from
what images supply. But this is not the point under discussion.

I think ``IMPLIED'' is a sufficient condition. <IMG> which author
doesn't specify alternate text is decided so by author.

> > I point out some curiousities about ALT for <IMG>.
> > B.5.1 says: When an author does not set the alt attribute for the IMG or
> > 	APPLET elements,...
> > but now <IMG> requires ALT attribute and this condition never happen.
> 
> Even though it shouldn't, it will because many authors never pay 
> attention to the specs. Hence:

Why they don't? Because it is not a necessary condition but this
specification requires it. I think required specs should be necessary
conditions.

Now an HTML text which includes <IMG> without ALT is not an HTML 4.0
text and this description about <IMG> is unnecessary.

W3C-NOTE is suitable for such notes probably.

> > 	  2. Otherwise, if HTTP headers provide title information when
> > 	     the included object is retrieved, this information should
> > 	     be used as alternate text. 
> > 
> > Which field of HTTP headers?
> 
> Title:

But it is not written anywhere. It should be stated clearly.

> > 	  3. Otherwise, if the included object contains text fields
> > 	     (e.g., GIF images contain some text fields), information
> > 	     extracted from the text fields should be used as
> > 	     alternate text. Since user agents may have to retrieve an
> > 	     entire object first in order to extract textual
> > 	     information, user agents may adopt more economical
> > 	     approaches (e.g., content negotiation). 
> > 
> > This means all user agents must GET image datas when they fail 1 &
> > 2. And this requires user agents to analyze image datas too. Really? I
> > think it's stupid.
> 
> Somewhat, but when bandwidth isn't a problem, it isn't as stupid.
> Some formats such as GIF and PNG allow comments to be embedded
> near the beginning of the file.

Problems are:

	- User agents can not know bandwidth of network which it's
	  using in advance and probably it would be changed
	  dynamically.
	- User agents can not know its image data size in advance.
	- User agents can not know its image format in advance.
	- User agents can not know whether any strings are included or
	  not before they download and analyze it.

and...

> The problem I see is that suddenly pages with no ALT= text for their 
> images will have bizarre messages like "(c) 1997 XYZ, Inc." or more 
> embarrassingly  "FooBar Imagizer. Unregistered version." extracted from 
> the comments.

Exactly.

> > 	  4. Otherwise, in the absence of other information, user
> > 	     agents should use the file name (minus the extension)
> > 	     as alternate text. 
> > 
> > What is `file name'?
> 
> The URL without the protocol, server, port, and path. So
> 
>   <IMG SRC="http://www.mysite.net/images/border.gif">
> 
> Would show up as
> 
>   "border"

Huh, you say that
<IMG SRC="http://hostname/path/to/cgi-bin/nonsense-string"> would show
up as ``nonsense-string'' but it's not ``file name''. So I asked
``What is `file name'?''. You see?

How do user agents know whether `border.gif' is file name or not?
`border.gif' is a part of URL and it's not file name. So this
description is not proper.

-- Koga Youichirou

Received on Thursday, 18 September 1997 23:53:29 UTC