- From: Robert Burns <rob@robburns.com>
- Date: Tue, 21 Aug 2007 23:20:58 -0500
- To: Michael A.Puls II <shadow2531@gmail.com>
- Cc: "HTML Working Group" <public-html@w3.org>
Hi Michael, On Aug 21, 2007, at 10:45 PM, Michael A. Puls II wrote: > >> No, I don't think Opera or iCab are going with a default width and >> height. It looks to me like their extracting the intrinsic dimensions >> of the media and using that. That to me is what the behavior should >> be for all browsers. > > For native handlers, Opera can figure out the intrinsic dimensions and > use those if none are specified on the object, which is good. > > For plugins in Opera, it's a different story. If you don't specify the > width and height on the object, the object will be 150 x 150. The only > way that it won't be is if the loaded plugin detects the dimensions of > the media it's loading itself and resizes itself, but I'm not sure > what plugins do that. I see. > For example: > <object type="application/x-mplayer2">wmp</object> > <object type="application/x-java-applet">java</object> > <object type="video/quicktime">quicktime</object> > <object type="application/x-shockwave-flash">flash</object> > <object type="audio/x-pn-realaudio-plugin">realplayer</object> > <object type="video/divx">divx</object> > <object type="application/x-vlc-plugin">videolan</object> > <object type="application/x-xstandard">xstandard</object> > <object type="application/x-tcl">tcl</object> Regarding this list, have you checked on all of these, or are you simply compiling a list of plugins to check? Just as I think it makes sense for the browser to lookup intrinsic dimensions with its internal handlers, I also think it would be best practice for certain plug-ins to do the same. For example, I would think something like Java would really need to manage this by either accepting the dimensions it was given and resizing the user-interface appropriately or insisting on the dimensions it needed for the applet. For plugins handling audio, obviously that's not so important. It might be worth it then to try to figure out what common plugins behave this way. It is not a real hight priority to me, but it may be worth investigating. My primary aim here was to learn what the handlers (internal or external) do for the most common types of embedded content. If OBJECT is evolving to the point where it can handle PNG, JPEG, GIF and SVG as well or better than IMG then that's a significant step forward. If it can also ease the embedding of audio and common video formats (primarily through WMP, QuickTIme, etc). then that's even better. > <script> > window.onload = function() { > var obj = document.getElementsByTagName("object"); > for (var i = 0; i < obj.length; ++i) { > alert(getComputedStyle(obj[i], null).getPropertyValue > ("width")); > alert(getComputedStyle(obj[i], null).getPropertyValue > ("height")); > } > }; > </script> Thanks for producing that little script. I'll try to see how I can incorporate that into our tests. > In Opera, (assuming you have all those plugins), you'll get 150px for > every one. Now, even if you give the plugin a 400 x 400 video to load > for example, it'll still show as 150 x 150 unless the plugin resizes > itself on its own. > > If so, FF would need something like (made up): > > object:loaded { width: 150px; height: 150px;} in its default style > sheet. > > (I could be mistaken, but that's how it appears to me.) Yes, I think that makes sense. The other thing that might make sense would be do limit the dimensions of the embedded content to some percentage of the viewport or the enclosing element (perhaps 90% - 110%). I don't really think it serves the user at all to have the embedded content spilling out of the viewport. I think this preliminary investigation of this issue indicates we have very close to interoperability in the latest releases of the browsers (Safari may be the one exception). The intrinsic dimensions part is really gravy. We should really have it on OBJECT since IMG behaves that way. However, I don't imagine many authors omit dimensions entirely. Take care, Rob
Received on Wednesday, 22 August 2007 04:21:13 UTC