Re: Equivalents (was Re: Multilanguage alt/title)

On Aug 29, 2007, at 8:35 PM, Sander Tekelenburg wrote:

>
> At 19:27 -0700 UTC, on 2007-08-29, Maciej Stachowiak wrote:
>
>>> On Aug 29, 2007, at 7:41 PM, Maciej Stachowiak wrote:
>
> [... Re <http://esw.w3.org/topic/HTML/ObjectSupport>]
>
>>>> Did you find any problems in Safari's support for the OBJECT
>>>> element for images? I don't recall you mentioning any.
>
> As I mentioned in
> <http://www.w3.org/mid/p0624062ac2f3582dbb44@%5B192.168.0.101%5D>,  
> Safari
> (2.0.4) doesn't present the image, but instead the contents of  
> <object>, when
> @type is set to image/*. (If that's fixed in Safari 3, that's  
> great :))

"image/*" is not a known MIME type, indeed I am not sure if it is even  
a legal type. It seems pretty simple to omit the type instead of using  
an illegal type, which likely makes us think we can't handle the  
content.

In the long run the right thing to do is to ignore the type attribute  
and choose how to handle the content based on the server-reported  
return type, which I guess is what Firefox is moving to.

> [...]
>
>> I believe it does size properly to intrinsic size of an image in
>> Safari 2
>
> It does, yes. (Well, at least for the PNG I tested with.)
>
> [...]
>
>> I think the HTML5 recommendation will be to use <audio> and <video>
>> for audio and video when possible. These provide for fallback  
>> content.
>
> Fallback, yes. But equivalents? The current HTML5 draft speaks very
> specifically of fallback only, and seems to mean <video><a  
> href="URL">click
> here</a></video>.

What would make the most sense to me is something like:

<video type="video/mp4" src="lolcat.m4v">
<object type="video/mp4" data="lolcat.m4v">
... text equivalent goes here, if needed ...
</object>
  </video>

However, a video file may have optional caption tracks and/or  
descriptive audio, so a text equivalent may not be necessary for  
accessibility.


>> Apple also has a proposal in the works for selecting one of several
>> media items for <audio>/<video> based on accessibility  
>> considerations.
>
> Looking forward to that :) Is it for <audio>/<video> exclusively, or  
> would it
> apply to stuff like <img>, <object>, <embed>, <canvas> and <table>  
> as well?

Our current proposal is for <audio>/<video> based on the fact that  
they can already list multiple <source> elements. It's meant to let  
you select an alternate video that has features like high contrast,  
burned-in captions, a descriptive audio track, etc. As such I don't  
think it would really apply to the other elements. I suppose one could  
image providing high-contrast versions of static images.

>
>
>> <embed> is there primarily for content handled by plugins. The best
>> plugin markup for degrading gracefully in a wide variety of browsers
>> nests <embed> in <object>
>
> But <embed> is empty; offers no way to provide equivalents. It may  
> be best
> today, but should that really be best tomorrow?
>
>> , and it would be unfortunate to make such
>> markup non-conforming [...]
>
> True, but we should do it in such a way that equivalents are possible.

I think we should define that when <embed> is nested in <object> and  
neither can be presented, the <object> element's fallback applies.

Regards,
Maciej

Received on Thursday, 30 August 2007 06:09:51 UTC