Re: handling fallback content for still images

HI Patrick,

Thanks for looking into that. (comments follow):

On Jul 3, 2007, at 7:02 PM, Patrick Garies wrote:

>
> Robert Burns wrote:
>> No that's fine. Thanks for trying. I'll get access to IE myself  
>> and see if I can come up with anything. Somewhere I read that  
>> adding the <param> as I did would get IE working. Maybe it's IE7  
>> only. Or maybe its just plain wrong (I think I got if off of  
>> Wikipedia).
>>
>> Take care,
>> Rob
>
> A brief test of…
>
> <object type="image/png" data="object.png">
>    <param name="src" value="object.png">
>    <p>This is fallback content.</p>
> </object>
>
> … showed that it didn’t work; Internet Explorer 7 renders what  
> looks like an empty “iframe” element instead. Neither the image  
> nor fallback content is shown.
>
> On the other hand…
>
> <object type="audio/x-pn-realaudio-plugin" data="D0005.ra">
>    <param name="src" value="D0005.ra">
>    <p>This is fallback content.</p>
> </object>
>
> … /does/ work [http://www.jsgp.us/demos/D0005.html]. Maybe  
> that’s where the idea for the “param” element came from.
>
> It looks like you can get Internet Explorer to render images via  
> the “object” element if you get rid of that “param” element:
>
> <object type="image/png" data="object.png">
>    <p>This is fallback content.</p>
> </object>
>
> However, the image is rendered as if it were it were in an iframe  
> and includes padding/margins; as a result, there are active  
> scrollbars surrounding it unless the “object” element’s  
> dimensions are larger than that of the image (including the padding/ 
> margins and width of the vertical scrollbar). Even if the  
> dimensions are large enough, Internet Explorer’s ever‐present  
> vertical (inactive) scrollbar remains and cannot be suppressed via  
> “overflow: hidden”. The frame surrounding the image (but not the  
> image itself) increases and decreases in size when the zoom feature  
> is used; this results in either excessive whitespace or scrollbars.  
> Fallback content is not displayed; you get what appears to be an  
> empty “iframe” element and an error dialog when the image cannot  
> be fetched.

Safari, successfully renders the image, but also presents a mis-sized  
iframe like object. I would imagine adding height and width  
attributes might help.  This is disappointing.

However, as I said before, these are issue that I would imagine the  
UA implementors could fix going forward without breaking any content  
(or very little content).  In other  words, most authors are forced  
to jump through extra hoops adding attributes and parameters to  
<object> to make their content render properly. That means no one is  
really getting away with displaying content without any parameters or  
attributes. So we could add conformance criteria for UAs to render  
<object> without any other attributes or parameters in reasonable  
ways for a whole variety of MIME types

<object date='anySupportedMimeTypeNativelyOrPlugin'>
fallback
</object>

I think such markup should display audio in the standard way (with  
the timeline and start/pause controls etc.). All visual media should  
be displayed without scrollers and without extra padding (in most  
cases). Obviously beyond a certain limit, the need for scrollers  
could arise, though this could be for the entire document or for just  
the object depending on what we want to recommend.

Doing this would be a great benefit whether we decide to  
differentiate video, audio, flash, etc. with their own element types.

Take care,
Rob

Received on Wednesday, 4 July 2007 01:03:34 UTC