Re: the market hasn't spoken - it hasn't bothered to listened [was Re: fear of "invisible metadata"]

At 00:00 -0700 UTC, on 2007-06-26, Maciej Stachowiak wrote:

> On Jun 25, 2007, at 10:08 PM, Robert Burns wrote:

[...]

> I would be ok with an image element that supports true fallback, but
> I don't think a linked separate document is quite the same thing as
> fallback content.

Indeed. <pic>fallback</pic> and <a rel="longdesc"> are just as different as
alt and longdesc are.

[...]

> <style>
> .fallback { display:none; }
> </style>
>
> <picture src="foo.jpg">
> <img src="foo.jpg" alt=""> <!-- empty alt text since this is for
> fallback in UAs that don't have <picture> support -->
> <div class="fallback">
> ... fallback content here ...
> </div>
> </picture>
>
> I'm not sure if it is worth it going to such lengths for an img
> element with markup fallback.

Not to mention that this would make pages (author-)CSS-dependant. When the UA
ignores the author CSS, the user will be presented with the fallback content
even when the image is presented already.

>> The only other issue that I think would need to be addressed is
>> that of the @alt attribute. Clearly the @alt attribute has the same
>> advantages for other embedded content elements that it has for
>> <img>. We should consider adding @alt to all non-text elements: not
>> as fallback content, but as the quick and short alternate text for
>> non-text media.
>
> The text alternative for such elements is their actual content. This
> is better than an alt attribute because it allows general markup. I'm
> not sure why alt is desired in such cases.

Me neither.

>> We may also want to think more about the differences and
>> similarities between @alt and @title and provide implementors and
>> authors with clearer guidance on how these might be handled and
>> used together.
>
> alt is an alternative, a title is auxiliary. Seems pretty clear to me.

IE renders the contenty of alt even when the image is loaded. So apparently
it isn't clear to all UA developers.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Tuesday, 26 June 2007 12:39:03 UTC