Re: an interoperable object (fallback and context menus)

Hi Leif,

These are some great, detailed, and clear tests you have produced Leif.

<http://malform.no/html5/object>

We should consider what bugs can be fixed in the major browsers and  
also what language the HTML5 draft needs to include to keep UA  
handling of objects embedded with the 'object' element consistent.

Ideally, embedding an image with <img src='image' alt='alternate  
content'> and <object data='image'>alternate content</object> should  
produce the same user experience (though the latter permits richer  
marked-up alternate text). This first step is what Leif's most recent  
tests focus upon.

The next step then is also to make it so embedding anything (or at  
least video, audio, or still image) is as easy to do as <object  
data='resource' >alternate content</object>. Whether we need 'video',  
and 'audio' elements should be a separate issue. In many ways these  
element needlessly complicate the HTML language, but if an author can  
use 'object' and rely on a consistent user experience for any embedded  
resource across UAs, that would be best.

As Leif alludes to, I did produce some earlier test cases on this.  
Though IE8 is an improvement, WebKit remains the same and I think  
Firefox actually got worse with 3.0 (note these tests/demonstrations  
are not anywhere as clear as Leif's, but they are helpful nonetheless).

This wiki page provides an overview:
<http://esw.w3.org/topic/HTML/ObjectSupport>

These two test pages linked from the wiki page provide comparisons of  
several image formats and a few video and audio formats embedded with  
the 'object' element (the second page uses a WebKit workaround by  
adding superfluous 'param' element to get the content to render  
correctly).
  - <http://lists.w3.org/Archives/Public/www-archive/2008Aug/att-0019/testObjectHTML.html#smallgif 
 >
  - <http://lists.w3.org/Archives/Public/www-archive/2007Aug/att-0027/TestObject.html 
 >

The goal with these pages was to get complete support for the 'object'  
element so that with the minimal markup, "<object  
data='resource'>alternate text</object>", the embedded content would  
just work (for common image, video and audio formats).

Getting embedding working in a consistent manner would do a tremendous  
win for authors and users. For a vast majority of use cases, most  
authors would only need to use the 'object' element and only need to  
provide the 'data' attribute and have it work as expected. Controls  
for spatial (full screen, resize preserving aspect ratio, change  
aspect ratio), temporal  (play, pause, stop, loop, scrub forward,  
scrub backward, go to  frame, go to time index), and audible (volume,  
mute, balance, alternate audio tracks, etc.) should just come along  
with this simple markup for free (in the chrome of interactive UAs).  
Similarly user defaults and real time selection of subtitles and  
captions should  just happen with this simple markup (for resources  
that include such alternate text).

Assistive technology support should likewise come along for free with  
this simple markup. We hear this type of AT for free authoring  
expounded often, but we haven't gotten 100% cooperation from  
implementors on this (though I commend the IE team for coming so far  
with IE8 and Opera achieved high marks right out of the gate).

Take care,
Rob

On Mar 12, 2009, at 2:04 AM, Leif Halvard Silli wrote:

> 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 Friday, 13 March 2009 00:24:13 UTC