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

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

>
> On Jun 25, 2007, at 11:40 PM, Maciej Stachowiak wrote:
>> Out of the suggestions so far, I like <a rel="longdesc"> the best.  
>> It would do something reasonable in existing UAs, could be applied  
>> to more than just images (videos or tables might merit a long  
>> description for instance) and would be accessed even in normal UAs  
>> without the use of accessibility tools, so would be more likely to  
>> be maintained. Arguably even today it is a better option than the  
>> img longdesc attribute.
>>
>> Regards,
>> Maciej
>
> I think there is some merit to the suggestion of <a rel="longdesc">  
> However, its in some ways too awkward and in other ways too late to  
> introduce an alternative. First we should keep in mind that  
> longdesc was added to <img> to deal with the deficiency in <img>  
> itself. HTML5 only highlights that deficiency even more in adding  
> other media (embedded content) elements that provide fallback  
> mechanisms. That is <canvas>, <video>, and <audio> all allow  
> fallback contents within the contents of the element itself. <img>.  
> and <embed> do not.  Typically then, to parallel the other media  
> elements, @longdesc would point to a trailing element on the same  
> page, whose "display" property is set to "none" when not needed and  
> displayed when needed by a user (to behave like the other elements'  
> fallback content).

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. But perhaps the latter is not ever actually  
necessary when you can have proper markup as fallback.

>
> So in the spirit of trying to push authors to follow better  
> practice (which is what some have said the conformance requirements  
> are for), <embed> should not be added to HTML5. Likewise, <img>  
> should be removed (and with it @longdesc). A new element should be  
> introduced (along with the other non-text media elements) such as  
> <image>, <pic>, <still>, etc. This new element would provide  
> fallback content as its contents. It would work like the other  
> modern embedded content elements, but with attributes as simple as  
> those for <img>. This would provide a path of good practice for  
> authors and make the language cleaner. It would also discourage the  
> use of the broken embedded content elements (<img> and <embed>).  
> Implementation of <still>, for example, would be no more  
> complicated than implementation of any of the other new embedded  
> content elements.

It might be ok to add a new element for still images that supports  
fallback content. But I would be against removing <img> or <embed>.  
They are needed to handle images and embedded content in existing  
browsers, and we should make sure there is a graceful degradation  
path that is still conforming. One possibility:

<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.

> 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.

> 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.

> Finally, I've mentioned this before, but it's worth mentioning  
> again. I think it would be good for us to provide guidance for UAs  
> to expose basic string metadata such as description and keywords  
> from the media files themselves to users.
>
> Any thoughts?

A metadata API for media files is a pretty complex thing to get right.

Regards,
Maciej

Received on Tuesday, 26 June 2007 07:01:21 UTC