Re: Empty vs no alt attribute (was Re: Baby Steps or Backwards Steps?)

On Aug 22, 2007, at 6:31 PM, Marghanita da Cruz wrote:

>
> David Poehlman wrote:
>> I was under the impression that alt was replacement.  perhaps we  
>> should have an attrib called replace=.
>
> I have now reproduced the alt information in a title field and  
> tested the page
> in Iceweazel and IE...
>
> IE defaults to the ALT text on mouseover when no TITLE present
> Iceweazel does not display ALT text when no TITLE present
> Both display TITLE on mouseover, if it is present.
>
> My excuse for using ALT instead of TITLE, is that many of my  
> webpages pre-date
> HTML 4. Given that there are other HTML 3 pages out there live or  
> archived. Care
> should be taken when introducing or changing the purpose of  
> existing tags.

This has nothing to do with HTML3 pages or old pages. This has to do  
wit authoring documents based on the behavior of one or more browsers  
and not he intended semantics of the tags. Creating a tooltip-like  
mouseover/hover view was never the purpose for the alt attribute. The  
alt attribute even in the original HTML specification[1] was:

"alternative text as an alternative to the graphics for display in  
text-only environments"

As an alternative to and not as a supplement to like a tooltip would  
be. A browser might provide the ability for a  user to display it  
that way (and it's a shame we have to discourage or qualify these  
things), but authors should definitely not abuse the semantics just  
because it gets the desired result in one browser.  That's an  
education and a evangelism issue,, but it's not about an ill-advised  
transition from pervious HTML recommendations.i

So if the @title attribute gets the behavior you want, then why not  
just use title. Would you only lose this tooltip-like support in IE 3?

> With images turned off...the alt text is displayed...mousing over the
> pre-allocated alt labelled space on the page provides the Title/Alt  
> text as above.
>
> When bandwidth is limited it would be useful to know the size (in  
> bytes) of the
> image and be able to download/view optionally....this could also be  
> relevant to
> video, audio and large documents.

It may be desirable for users to have fine-grained control over the  
downloading of linked and embedded resources. However, this does not  
necessarily directly correlate with limited bandwidth. It may be  
desirable for a browser to download resources immediately due to  
limited bandwidth. Loading many pages into separate windows or tabs  
while reading another page is a common practice among users and a way  
to deal with low bandwidth. If the browser fails to download the  
embedded resources when downloading the page, then this actually  
hinders the user in a low-bandwidth environment. Because now the user  
has to wait for resources to download instead of having them  
downloaded while the user was buy doing other things.

> As a sighted person, I don't believe that the use of graphics/ 
> buttons to hide a
> hyperlink adds to the web experience - but it would be difficult to  
> convince
> many of this.

Sorry, I'm not clear about what you're referring to here or how this  
relates to other portions of this post.

> With this attitude, I believe images should be used to enhance the  
> text - in
> which case they cannot be described satisfactorily. For example, I  
> described the
> ideas which Joel, an illustrator, translated into "Illustration of  
> Corporate Governance of ICT by Joel Tarling" <http:// 
> www.ramin.com.au/itgovernance/as8015.html>

If an illustrator is able to conjure up an image based on your  
description, why wouldn't a user who's unable to view the  
illustration not be able to conjure something up as well  (at least  
in their mind if not some other medium).

> Some do argue that this information should be in the metadata of  
> the image
> itself not in the HTML. Note in the above example, the copyright  
> notice is in
> the image itself.

I am one of those who would argue for rich textual metadata in  
images. However, that does not mean that the text doesn't belong also  
in the HTML. When tat image gets used in a document, the meaning of  
the image changes based on the context.  Often times the isolated  
description of the image may suffice, but other times it may only be  
a starting point. Further  changes  to the description may be needed.  
Also most UAs do not retrieve images and extract the textual metadata  
from them. Some browsers may be text only and so taking significant  
steps to add image support just to extract metadata may be difficult:  
to say nothing of the increased bandwidth of downloading an entire  
image just to get a snippet of text.

So keeping image libraries with textual metadata would be a good  
practice for anyone maintaining an image library. If an illustration  
was created from a written description, then storing that written  
description with the image makes a lot of sense: at least within the  
library of the creator of the image. Whether that metadata should be  
included in the image uploaded to the webserver is a separate issue.

Take care,
Rob

[1]: <http://www.w3.org/MarkUp/draft-ietf-iiir-html-01>

Received on Thursday, 23 August 2007 00:10:47 UTC