[whatwg] Conformance for Mail clients (and maybe other WYSIWYGeditors)

I think the correct fallback for a photograph for its own sake is alt="(Use
a browser that supports graphic images to view)".
The problem is that such images usually have an independent caption that is
visible with alongside the image.  Specifying a description of the content
of the image as the alternate text would probably duplicate that caption and
render a page that is hard to understand in a text-only browser:

Frisson: White truffle & wild rice
Frisson: White truffle & wild rice

And the viewer has no clue what that means.
Chris

-----Original Message-----
From: whatwg-bounces@lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Maciej Stachowiak
Sent: Wednesday, April 11, 2007 10:22 AM
To: WHAT working group
Subject: [whatwg] Conformance for Mail clients (and maybe other
WYSIWYGeditors)


This topic came up on #html-wg today.

Mail.app and other mail clients don't put alt attributes on images  
generated in email. They could add alt="", but there are two reasons  
it might be better to allow no alt attribute at all, at least for  
email clients.

1) A mail message is often sent to a restricted audience, so the  
accessibility, media-independence and machine-understandability  
benefits or alt are not nearly as great. And adding alt="" as a cargo  
cult talisman does not give these benefits in any case.

2) WYSIWYG editors in general can't be expected to enforce proper alt  
attributes. Users can add images in all sorts of ways (paste, drag  
and drop) that don't have a natural affordance for entering alternate  
text. And I doubt WYSIWYG editors that popped up a box for typing in  
text whenever the user inserts an image would be competitive


In general, I think the HTML5 definition of <img> is problematic - it  
says:

"The img element represents a piece of text with an alternate  
graphical representation."

And also:

"When the alt attribute's value is the empty string, the image  
supplements the surrounding content. In such cases, the image could  
be omitted without affecting the meaning of the document."


Let's consider one archetypical use of the <img> tag in the wild, a  
Flickr photostream. The example below is from my photostream.

<IMG src="http://farm1.static.flickr.com/ 
178/392969604_a0887f39ce_m.jpg" width="240" height="180" alt="">

I don't think it is right to say that this represents a piece of text  
with an alternate graphical representation - it represents an image,  
namely the linked photo. It's also not right to say that the image  
could be omitted without affecting the meaning of the document.  
Although I entered a title of "Frisson: White truffle & wild rice",  
it would be a strained interpretation to say my photostream page  
would have the same meaning without any of the photos. Also, Flickr  
lets me have no title at all, or an ugly title based on the camera- 
chosen file name like DSC0981.JPG.


Ian suggested that many uses of images on the web that aren't  
alternate graphical representations of text should be in the CSS  
layer. So maybe this should be <div id="photo1"> with a  
<style>#photo1 { background: url(http://farm1.static.flickr.com/ 
178/392969604_a0887f39ce_m.jpg); width 240; height: 180; }</style>  
somewhere. But that doesn't make sense to me - the photos in my  
photostream aren't presentational and a stylesheet that replaced them  
with other images would not preserve the image in the page. Further,  
browsers often do not offer as good interaction with background  
images as the contents of an <img> element. For instance, you can't  
drag a background image from the page to your desktop in any browser  
I know of. So that choice of markup would suck for the user, in  
addition to having the wrong split of presentation and semantics.

Although Flickr isn't what most people think of as a WYSIWYG editor,  
my choice is carefully considered. Embedding photos  is a fairly  
common use for meaningful images in blog posts, and blog editors  
should support them effectively.

So, in conclusion, I think the stated meaning of <img> and the  
requirement of an alt="" attribute need to be reconsidered in light  
of end-user-generated content.

Regards,
Maciej

Received on Wednesday, 11 April 2007 02:01:56 UTC