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

On Jun 26, 2007, at 12:48 AM, Robert Burns wrote:

>>> 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.
>
> Again, the removal of <img> and <embed> does not in any way  
> eliminate a graceful degradation path.

It removes a graceful degradation path from the conforming language.  
It should be possible to write conforming HTML5 documents that still  
work reasonably in the current generation of browsers. We should not  
force authors to choose between passing an HTML5 conformance checker  
and making a document that works in the browsers of 2007.

>>> 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.
>
> Well I don't have real strong feelings about this. I'd love to hear  
> from some others more familiar with accessibility. However, even  
> with rich fallback content like that provided by <object> and the  
> new embedded content elements, I think its still worth considering  
> whether @alt may still be needed (e.g., as an abbreviated version  
> of the fallback). Again, I think we should simply consider and  
> orient authors and UA implementors to how all of these properties  
> might interact: @alt, fallback content, @title, and media file  
> metadata.

<object data="foo.mpeg" alt="A kitten playing with yarn."></object>
<object data="foo.mpeg">A kitten playing with yarn.</object>

Doesn't look abbreviated to me.

Regards,
Maciej

Received on Tuesday, 26 June 2007 08:03:08 UTC