Re: More about <alt>

On 2007-09-06 15:56:34 +0200 Sander Tekelenburg <st@isoc.nl> wrote:
> At 05:05 +0200 UTC, on 2007-09-05, Leif Halvard Silli wrote:
>> 2007-09-05 04:10:07 +0200 Sander Tekelenburg <st@isoc.nl>:
>>> At 01:09 +0200 UTC, on 2007-09-05, Leif Halvard Silli wrote:

>> The advantage of @LONGDESC is that it has a special purpose.
> 
> That in itself is just as much a disadvantage ;) It forces authors to make
> the right choice: whether/how to use it, or @alt, or both.

A special purpose could also make it simpler for the author - e.g. it frees the author from e.g. (failing) to add 'long description' in the @TITLE . It might of course be that @LONGDESC was invented in a time where bandwidth was more of a concern that what it is today. But as we both agreed, @LONGDESC="URL" could serve a purpose in a photo album such as Flickr - by linking to the canonical description of the image.

>> Also, it is fair to be able to choose between long and short equal content
>> in some cases.
> 
> Sure, but the current <alt> proposal makes that entirely possible. It just
> doesn't include a defined method to indicate short vs long textual
> equivalents. It currently relies on authors indicating that through sensible
> @title use...

There is nothing in the keeping of @longdesc which prevents the user from offering two <ALT>-versons - a short and a long. But lets consider our example with the photo-album again: More things could go wrong without @LONGDESC than with, I think.  The user doesn't need or want to read 'short description' or 'long description' - the user just want the link to the canonical long description.

[ … how Flick could improve with @LONGDESC … ]

>> an extra LONGDESC/@LONGDESC link that links directly to an authorative
>> description of each particular image?
> 
> Hm... You mean on a page with multiple different images, have a single link
> to a single resource containing the equivalents for all those images? 

Below you describe exactly what I meant:

>> That way e.g. unsighted and text users do no have to click themselves
>> through unlimited levels and size versions of the same image.
> 
> They don't have to anyway. As I said in another message: <a
> href="bigimage.jpg"><img src="thumbnail.jpg" longdesc="URL"></a>.

Exactly.

>> And also, Flickr or whatever would not need to have the same, long, ALT
>> text on all pages for all images.
> 
> You would still need all equivalents available from every size version of the
> image, because you can't be sure that a user will enter your site through one
> or the other door.

Of course. (What I tried to convey was that they do not need to have the long description/long equivalent on each image. The @alt text could instead be more 'functional'.)

> [... <alt>]
> 
>>>> Plus one would get to see the img @TITLE via tool tip for free ä ;-)
>>> 
>>> Well, that in itself should be solved anyway, now that the spec says
>>> that UA must present @alt and @title differently.
>> 
>> ;-) Yeah. So you mean we don't need to think about how it technically could
>> be solved?
> 
> I can't follow. How *what* could be solved?

Browser implementations: IE7 supports the CSS selector IMG:hover+*{} - so once IE7 supported <ALT>, we could certain that it would be simple to show the alt text alongside the image. Or do you think that even with <ALT> they could suddenly get the idea that «we want to show this as tool-tip when the @TITLE is ‹lacking›»? Well - it could happen, of course.

[ …  ]
>> 2) what about this special IMG case construct - i.e. keeping the IMG inside
>> the ALT:
>> 
>> 	<html><p><alt><img alt=""></alt>
>> 
>> 	Then an AT UA would not be able to skip the text of the <ALT> element. And
>> the empty @ALT on the IMG would make sure that we do not get any «double»
>> alt-text whether in the GUA or the AT UA.
> 
> Yeah, but what about HTML5 UAs that generally will show the image by default?
> The idea is that HTML5 UAs do not present all equivalents (unless the user
> wants that). So the idea is that authors/UAs/users can set <alt> to
> display:none.
> 
> So an <img> embedded in <alt> would then also not be displayed.

The above example would have to be a special case. That UA preference needed not to hide this special case.  And perhaps, when the <ALT> contains only one element - and isn't linked to any thing else, then its primarly content should be displayed. (Or else, the <ALT> would become a method for providing hidden info a document, I think.) You must also consider that an IMG, in existing UAs cannot have anything but alt _TEXT_. (In reality, it seems as if the <ALT>-proposal is just another arguement for moving away from the void IMG element over to OBJECT or PICTURE.) 

>> The only drawback would be that it perhaps became difficult to find a bug
>> free way of hiding the <ALT>-element but keeping the IMG element visible?
> 
> Exactly... :)

Suddenly you had no problems with getting that it was a browser implementations argument …
-- 
leif halvard silli

Received on Thursday, 6 September 2007 15:41:36 UTC