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: Chris Wilson <Chris.Wilson@microsoft.com>
Date: Tue, 21 Aug 2007 14:06:22 -0700
To: Robert Burns <rob@robburns.com>
CC: HTML Working Group <public-html@w3.org>, "wai-xtech@w3.org" <wai-xtech@w3.org>, Sander Tekelenburg <st@isoc.nl>, "Gregory J. Rosmaita" <oedipus@hicom.net>
Message-ID: <5C276AFCCD083E4F94BD5C2DA883F05A27F79121B9@tk5-exmlt-w600.wingroup.windeploy.ntdev.microsoft.com>

Robert Burns [mailto:rob@robburns.com] wrote:
>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.

Ah.  Yes, the default IE in a Server system is very very locked down.  OBJECT is shut off - I'm pretty sure SCRIPT is too.

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.

>> 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.

For images (JPEG and GIF, at least), you'd still have scrollers.  For the other media types like QT, etc., it's up to the ActiveX control - so they would probably rescale (QT does, Windows Media Player does, e.g.).

>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).

I'd be surprised if there's video support in browsers like Konqueror but they can't handle old-skool MPG.

>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.

Really?  I didn't think I'd installed it, and it's on my (relatively new) MacBook.  Maybe I did go looking for a WMV player at some point, my bad.  And no, I definitely do not have inside knowledge there.  :)  At any rate...

>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

Yup.  The formats aren't required, and video codecs are typically very IP-restricted, which is why I think you can't really test QT or WMV or really any fairly recent codec - they're too charged, and they are not required by HTML (4.01).

>...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).

Sort of.  The big difference (to us, anyway) is that we natively KNOW about JPEGs.  We know how to get its intrinsic sizes, e.g.  We don't natively know about QuickTime - we'll have to rely on the QT ActiveX control telling us how big it should be.

Received on Tuesday, 21 August 2007 21:06:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:27 UTC