On Aug 29, 2007, at 6:11 PM, Robert Burns wrote:
> Hi Maciej,
>
> On Aug 29, 2007, at 7:41 PM, Maciej Stachowiak wrote:
>
>>
>>
>> On Aug 29, 2007, at 4:31 PM, Robert Burns wrote:
>>
>>>
>>> HI Gregory,
>>>
>>> After producing the wiki page on OBJECT element support in the
>>> latest browsers, I"m even more convinced this is the way to go
>>> [1]. From the results so far, it seems that every current browser
>>> except Safari allows for a simplified use of the OBJECT element
>>> (as nearly as simple as the IMG element except that for IE the
>>> dimensions need to be specified). The OBJECT element is much
>>> closer to being a replacement for IMG than I would have thought.
>>> If these bugs in IE (extracting and using the media's intrinsic
>>> dimensions) and Safari (not even handling this content at all)
>>> could be worked out, we would be there.
>>
>> Did you find any problems in Safari's support for the OBJECT
>> element for images? I don't recall you mentioning any.
>
> Not in the latest nightly builds, but in the release version and
> even the publicly released beta, it does not adjust the OBJECT
> generated box to the intrinsic dimensions of the media.
I believe it does size properly to intrinsic size of an image in
Safari 2, but I could be wrong. In any case, you can expect the
official Safari 3 release to be more like current nightlies than like
the beta.
>> The problems with audio/video are a bug in the quicktime plugin - I
>> hope that can be fixed soon but in the meantime you can duplicate
>> the data attribute in a <param name="src"> to work around it. In
>> any case they would not affect the use of OBJECT for images.
>
> Thanks for that information. I'll update the wiki with that
> information. I understand that it would not effect images since
> they're handled by WebKit internally. However, the same problem
> Gregory is talking about gets repeated for video and audio since we
> have a non-standard EMBED element that authors often turn to because
> the implementation of OBJECT (in both browsers and handler UAs) is
> inadequate. Again the non-standard EMBED element provides no
> mechanism for alternate equivalent fallback in the contents of the
> element.
I think the HTML5 recommendation will be to use <audio> and <video>
for audio and video when possible. These provide for fallback content.
Apple also has a proposal in the works for selecting one of several
media items for <audio>/<video> based on accessibility considerations.
<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>, and it would be unfortunate to make such
markup non-conforming, even if you can use <object> alone to target
newer browsers only.
Regards,
Maciej