W3C home > Mailing lists > Public > wai-xtech@w3.org > August 2007

Re: IE's AND EVERYONE ELSE'S object implementation problems (was RE: Baby Steps or Backwards Steps?)

From: Robert Burns <rob@robburns.com>
Date: Tue, 21 Aug 2007 12:56:23 -0500
Message-Id: <4C4A5688-1BBE-4F55-B956-C15CE1508607@robburns.com>
Cc: HTML Working Group <public-html@w3.org>, wai-xtech@w3.org, Sander Tekelenburg <st@isoc.nl>, "Gregory J. Rosmaita" <oedipus@hicom.net>
To: Chris Wilson <Chris.Wilson@microsoft.com>

Hi Chris,

On Aug 21, 2007, at 10:59 AM, Chris Wilson wrote:

> Robert Burns [mailto:rob@robburns.com] wrote:
>> What I've found is this:
>>  * IE7 (7.0.5730.11): Fails every test. ... (sorry Chris).
> I didn't ask because I wanted a particular answer, I asked because  
> I wanted to understand the problems as you see them.

I understand. Actually it turns out I wasn't testing properly. I'm  
pretty lost when I'm on Windows and I'm using terminal services to  
get to a Windows 2003 Server box. I have that sentinel thing running  
and I think that's why I'm getting text fallback and not the 0x0  
images you speak of. I'm trying to figure out now how to change those  
settings (it's not a mission critical server or anything; I just need  
it for the terminal services). Once I get that sentinel stuff figured  
out, I'll be able to do this IE testing better myself.

>> It presents the fallback content for every image, video and
>> audio file
> Actually, no it's not (notice the fallback text isn't there) - and  
> on purpose.  The #1 problem as I see it for IE's <object> support  
> today is that IE does not pull out an intrinsic size from the  
> object data.  We _ARE_ displaying the objects - we are displaying  
> them with a size of 0x0.  Yeah.  I'm not defending this, just stating.

I see. Does that mean simply adding some dimensions would display the  
content scaled to fit? Or would it still involve scollers? Either  
way, it sounds like a small step to peek into those intrinsic  
dimensions and get it working with these most simple OBJECT elements.

> The #2 problem is that images we know how to natively handle - JPG  
> and GIF, at least, but I think PNG too - are handled by IE's native  
> JPG display by basically embedding an IFRAME in place of the OBJECT  
> (this isn't really what's happening, but functionally it's an  
> appropriate way to think of it.  This means we get a small default  
> padding (cf navigating to a large JPEG file - there's padding), and  
> scrollbars if you overflow.

I see.

> Both of these are solvable, of course.

Yeah, it sounds like it.

>> This could be due to the video formats I chose, but since the images
>> were not handled either I doubt it. I would imagine that anyone with
>> a recent QuickTime/iTunes installed on Windows should be able to
>> handle this content.
> Only if QuickTime installs itself as an ActiveX control that  
> handles that media type.  I think it does, but I'm not sure.  I  
> would not recommend 3GP or QuickTime as a trial test, because it  
> relies on a non-default install - I would recommend .MPG.  Old, no- 
> interframe-compression MPG.  Even Windows Media format would be a  
> better choice, since Mac OS X at least comes with Flip4Mac  
> installed, but I would stick with MPG.

Yeah, I don't work with video regularly. Since this was a first shot  
at this I just wanted to get something small up there and so I picked  
the export to iPhone setting and that's what I got. I'll try to get a  
small click of .MPG without any fancy compression to make it more  
interoperable (though I suppose we still might have Linux and BSD  
problems for browsers like Konqueror).

BTW, Flip4Mac isn't installed by default on Mac OS X (unless you let  
an NDA comment slip :-) ).  Although it is a free download, not  
everyone knows about it.  So in this case I think we can expect  
QuickTime to be on Windows much more often than we can expect  
Flip4Maca and WMP to be on a Mac.

Though for testing we definitely want to make sure we're testing the  
browser and not the environment, so we might want to even provide  
multiple formats through the fallback mechanism or separate OJBJECT  

> Thanks for digging in to this.

Sure, no problem. Perhaps I'll try another version with some heights  
and widths thrown in. Like I said (and this has come from other  
members too) it would be great if some day authors can just rely on  
OBJECT elements' for most all their embedding needs and have it be as  
easy to use and reliable as IMG is today (but with the greater  
functionality and flexibility of OBJECT). The height and width don't  
really add that much complexity and it's fairly easy for even novice  
authors to understand, but if we don't need on IMG we shouldn't  
really need on OBJECT (at least for many common formats).

Take care,
Received on Tuesday, 21 August 2007 17:56:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:25:17 UTC