- From: Robert Burns <rob@robburns.com>
- Date: Tue, 21 Aug 2007 12:56:23 -0500
- To: Chris Wilson <Chris.Wilson@microsoft.com>
- Cc: HTML Working Group <public-html@w3.org>, wai-xtech@w3.org, Sander Tekelenburg <st@isoc.nl>, "Gregory J. Rosmaita" <oedipus@hicom.net>
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 elements.. > 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, Rob
Received on Tuesday, 21 August 2007 17:56:38 UTC