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