- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 29 Aug 2007 19:27:14 -0700
- To: Robert Burns <rob@robburns.com>
- Cc: "Gregory J.Rosmaita" <oedipus@hicom.net>, Olivier GENDRIN <olivier.gendrin@gmail.com>, public-html <public-html@w3.org>
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
Received on Thursday, 30 August 2007 02:27:28 UTC