Re: handling fallback content for still images

On Jul 1, 2007, at 2:55 PM, Robert Burns wrote:

>
> I imagine there's already a a Wiki page on this, but I thought I'd  
> post this here first. Late, I'll add this to the appropriate page  
> or perhaps this warrants a new page.

I think you should put this info in a wiki page. However, one thing  
to keep in mind is that a new <picture> element or similar would  
require the ability to fall back to <img> for UAs that do not have  
support for it. It may be tricky to set things up so that <img> is  
used in older graphical UAs, and the regular fallback content is used  
in non-visual or text-only UAs. I think a solution to this problem  
would be required to have a good proposal for a new element for still  
images.

Regards,
Maciej

>
> Problem: There's no simple and unified mechanism to display still  
> images in HTML with optional rich fallback content.
>
> Solutions:
>
> 1) <picture>fallback</picture>
>
> <picture
> 	src="picture.png"
> 	width="100%"
> 	height="500"
> 	alt="abbreviated fallback content"
> >
> Some lengthy <em>or</em> semantically rich fallback content
> </picture>
>
> pro: as simple to use as <img> and if widely implemented would  
> likely be widely adopted by authors
> pro: requires no special CSS or scripting
> con: not yet implemented in any UA (as far as I know)
>
> <object
>
> 	type="image/png"
> 	data="picture.png"
> 	width="100%"
> 	height="500"
> >
> 	<param
> 		name="src"
> 		value="picture.png" /
> 	>
> Fallback content
> </object>
>
> pro: already works in existing UAs
> con: difficult for authors to use
> con: makes adding fallback content seem difficult to do since the  
> difficulty with dealing with <object> and <param> and MIME Types,  
> etc are all associated by authors with simply adding some fallback  
> content
>
> <img
> 	src=picture.png
> 	width="100%"
> 	height="500"
> 	alt="Fallback content"
> >
>
> pros: works in existing UAs
> con: no semantically rich or media rich fallback is facilitated
> con: @alt is typically expected to be a short fallback, so lengthy  
> fallback is not facilitated
> con: its not unified in the sense that images with fallback must be  
> embedded in a different manner than images without fallback and  
> that fallback for some embedded content (like <object>) is handled  
> in a simplified way while <img> requires more complicated tacked-on  
> methods.
>
> for for lengthy or semantically rich fallback content
> <img
> 	src=picture.png
> 	width="100%"
> 	height="500"
> 	alt="abbreviated fallback content"
> 	longdesc="#pictureLongDesc"
> >
> <p
> 	id="pictureLongDesc"
> 	style="visibility: hidden;"
> >
> Some lengthy <em>or</em> semantically rich fallback content
> </p>
>
> pros: works in existing UAs
> con: requires special CSS or scripting (or loads a separate page  
> for fallback if the @longdesc points to another page)
> con: its not unified in the sense that images with fallback must be  
> embedded in a different manner than images without fallback and  
> that fallback for some embedded content (like <object>) is handled  
> in a simplified way while <img> requires more complicated tacked-on  
> methods.
>
> Again, adding picture adds complexity to the language. But we're  
> already adding elements with much less need (as far as I can tell)  
> like <canvas>, <video>, and <audio> that can all be handled with  
> <object> without much added difficulty (especially when compared to  
> moving from <img> or <picture> to <object>).
>
>

Received on Monday, 2 July 2007 17:34:49 UTC