- From: Leif Halvard Silli <lhs@malform.no>
- Date: Thu, 12 Mar 2009 08:04:17 +0100
- To: HTMLWG <public-html@w3.org>, Maciej Stachowiak <mjs@apple.com>, Chris Wilson <Chris.Wilson@microsoft.com>
The draft says that "The object element can represent an external resource, which, depending on the type of the resource, will either be treated as an image, [...]". Supposing that "as an image" means that the element will be treated as an image inserted via the IMG element, then currently Internet Explorer 8beta and Safari 4beta fails to treat OBJECT as drafted - in the following aspects: 1. Fallback: It is difficult to serve IE8 something that *it* can handle while at the same time getting IE7 and IE6 to instead display what *they* can handle = to display fallback. * In this regard, here is one possible option - which is also an cross-browser issue: The combination of cool uris (data="image" instead of data="image.png") and lack of type="" attribute (e.g. no type="image/png") does not work in Internet Explorer 8, 7 og 6 or in any version of Webkit (including the Safari 4 beta). Example code: <object data="image-without-mime-suffix">fallback.</object> * In IE8, that image is simply not shown - instead one get fallback, if there is any. If IE8 would have actually displayed that image, while IE6 and IE7 would not, then authors would have had a way that they could server something to IE8 and while serving fallback to IE6 and IE7. * In Webkit, the cool URI appears to work, except when you change the dimenson of the image via CSS or the width/height attributes to something that differs from the actual dimensions of the image - then one get scrollbars instead (much the same scrollbars as IE6 and IE7 display.) 2. Contextual menus: In Webkit, when cool URIs are *not* used (aka when the file has a suffix), and/or when the type attribute is used, then there is another problem: No contextual menus. (For the <img> element, one can activate the image with the mouse and one will get a contextual menu whereby one can save, send or copy its URL of the image, etc. This fails for OBJECT, in Webkit. [However, for cool URIs, the context menu is present even in WebKit.]) Neither of these problems exist in Opera, Firefox 3 or or in iCab before it went Webkit. Regarding the first issue: OBJECT is kind of useless today because IE6 and IE7 do not handle them right. The effect of the fact that IE8 has improved its handling of OBJECT so much (Chris appears to have really taken Rob issues seriously! [1]), will be hampered by the fact that any valid image served with OBJECT will look lousy (with scrollbars) in IE6 and IE7. And the fact that both IE6, IE7 and IE8 also currently agree to not attemt to display the content of OBJECT if they have cool URIs (but instead to show the fallback), means that there is no way (if there is, then the IE team should maake it known) to serve an OBJECT that will be displayed in IE8, but which will fall back to the fallback in IE6 and IE7. A use case: If IE8 would start to accept cool URIs in the data="" attribute, then there would at least be one way of serving e.g PNGs with alpha channel transparency to IE8, and some kind of fallback to IE7 and (especially) IE6. The problem in IE6 and IE7 really isn't the scrollbars per se, but rather the fact that IE6 and IE7 fail to show the fallback in place of those lousy scrollbar images. Had IE6/IE7 used the fallback instead, then OBJECT would have worked much better - as of today. It is a problem that authors do not have a certain way to govern whether a certain browser should display OBJECT or its fallback. More presicely: The user agents needs to know when they have failed to show the content, so that they can show the fallback instead. The contextual menu issue in Webkit is probably caused by Webkit deferring the issue of taking care of the display of OBJECT to QuickTime. (Browsers without the same intimate relationship to QuickTime as Webkit has, do not have this issue.) The issue might not seem very serious on the surface, perhaps. However, it still is likely that OBJECT's inaccessibility (due to this lack of the context-menu) will a) make it less accessible to AT users (VoiceOver?) and b) that it authors will be reluctant to serve GUI users images that are impossible to access with the mouse. (As for the trouble with cool URIs, Webkit does show the context-menu for those images, and hence Webkit appears to handle those images natively instead of sending the issue to QuickTime.) In summary: IE8 appears to have a more complete support of images via the OBJECT element than Webkit has. But the problem with IE8 is interoperatibility with previous versions of IE. (IE8 has here gotten the same problem that other UAs always had ...) Object is sometimes recommended as the preferred solution to the @longdesc usecase. However, for that be a real option, it must be simple to use OBJECT in place of IMG - without affecting GUI users or accessibility. For test cases and test results, se: http://malform.no/html5/object [1] http://lists.w3.org/Archives/Public/public-html/2007Aug/0785.html -- Leif Halvard Silli
Received on Thursday, 12 March 2009 07:05:00 UTC