[html4all] Object element support

[Robert J Burns]

Hi Jason, Leif and all,

On Aug 20, 2008, at 4:03 AM, Jason White wrote:

> On Tue, Aug 19, 2008 at 01:45:11PM +0200, Leif Halvard Silli wrote:
>
>> That might be. But if so, then it seems to that it is a bug which
>> has turned out to become a feature.
>
> I'm not persuaded that it is a feature. Personally, I don't care  
> about the
> distinction between "short" and "long" alternatives, but only that  
> there is an
> alternative that adequately substitutes for the image.
>>
>>> Of course, if the author so desires, the alternative can
>>> include a link referring to additional information. This is
>>> true of OBJECT as well:
>>>
>>> <object data="image"><p>An image. <a
>>> href="description.html">See this description for full
>>> details.</a></object>
>>
>>
>> That to me is not different from
>>
>> 	<p><img src=src alt="" />
>> 	Short.
>>         <a href=longDescription >Long.
>> 	</a></p>
>>
>>
>>
>> (But then, why would be need @longdesc?)
>
> The two cases are very different. In the OBJECT case, the fact that  
> the link
> is contained in the OBJECT element establishes that it is part of the
> alternative to the image. In your IMG example, the link is not, and  
> cannot be,
> included in the IMG element without the use of @longdesc. Hence, the  
> image and
> the link are semantically unrelated so far as the markup is concerned,
> whereas, by definition, the content of the OBJECT element serves as an
> alternative to the resource referred to in @data.
>
>>> However, assuming that this is considered a
>>> problem worth addressing, I can think of several alternative
>>> solutions:
>>>
>>> a. To define the semantics of @title on OBJECT as serving the
>>> purpose of providing a short alternative.
>>
>> Why would that be better than adding @longdesc to OBJECT?
>
> OBJECT already supports block-level content. The only reason for  
> creating
> @longdesc in the first place was that IMG didn't support inline or  
> block-level
> content. Since OBJECT doesn't have this design shortcoming, there is  
> no need
> for @longdesc, and including it would create a lot of confusion  
> regarding how
> to treat block-level content vs. the resource referred to by  
> @longdesc.
>>
>>> c. To define <a rel="alternative"> so that the link can be
>>> identified as a long alternative to the object.
>>
>>
>> For use inside Object? Like this:
>>
>> 	<object image=data>Short.
>> 	<a href=long rel=alternative>Link
>> 	</a></object>
>>
>>
>>
>> Then you are also saying that the first fallback is naturally short.
>
> No, this is precisely what I am not saying. The fallback can be  
> inline or
> block-level, and as long as the author wishes it to be. However, if  
> the author
> wants to provide only a brief alternative in the text as a  
> substitute for the
> image, and more detail separately which the user can access, then it  
> is
> possible to do so by means of a link.
>
> The IMG element forces a distinction between "short" and "long"  
> alternatives.
> OBJECT has the advantage, in its design, of not doing so. If I want  
> to provide
> a table as an alternative to a chart, I can do so without having to  
> create a
> separate page and using a link or @longdesc, provided that I use  
> OBJECT rather
> than IMG.
>
> This is an advantage of OBJECT over IMG, and has long been  
> acknowledged as
> such.

I really think we should get away from the short / long distinction. I  
would prefer to say that the IMG element forces a distinction between  
plaint text (and fairly easy to author) and rich markup text (and a  
little more cumbersome to author). On the other hand, OBJECT (and  
XHTML2 IMG) does not force this distinction. The length doesn't  
matter. The alt text should be whatever length is needed to serve as  
the alternate for the embedded media.

However, I think longdesc (and to a certain extent aria-describedby)  
provides another function that is useful beyond solving the problems  
of the text/html IMG element. That is providing a form of text  
equivalent for non-text media that is different from the alt text  
(that within the contents of the element or the value of the alt  
attribute). That is it can serve as a way to provide a description of  
the media that supplements the alt text. This is a distinction that I  
think is at the heart of this controversy over Flickr and alt text.

As an example I ran across this blog page[1]. About midway down the  
page is a photograph marked up with a figure and a caption (actually  
with div elements but used in the same way as HTML5 proposes) and the  
caption includes the text:

"Coal power plant. Coal is still dominant energy source for  
electricity production in US. <br>Click on picture for full size."

The photo is marked up with alt=''

The picture is of a coal power plant silhouetted along a waterway with  
the dusk sunset (or dawn sunrise) in the background. The plant is  
spewing smoke and steam into the air and we can see the conveyor that  
delivers coal to the plant.

My contention is that the description I just gave in the previous  
paragraph would be suitably referenced from the longdesc attribute  
(whether from IMG, OBJECT or any other embedding element). I feel that  
such text is not necessarily suitable for the alt attribute or as the  
contents of an OBJECT element because the reader loses nothing by  
missing the photograph and simply reading the caption. However, it  
would be a valuable service to users unable to consume the image to  
provide such a description in referenced by the longdesc attribute.

So to me such text does not qualify as alt text and does not have the  
same urgent status as the alt text and so should not be treated the  
same by HTML5. For example, we shouldn't necessarily require such text  
when it isn't integral to comprehending the document/page. Instead we  
should have alt text and we should have another mechanism for further  
text equivalent (especially for photographs) that is available (but  
not required) for those authors who go beyond the bare minimum of  
requirements. I note also that this example is contrary to Ian's claim  
that if the text is needed it should be provided to everyone in the  
caption. Those of us looking at the photograph do not want to read  
that description. So there are three types of text here: 1) alt text;  
2) caption text; and 3) descriptive text equivalent. But we've been  
trying to make these three types of text fit into two categories which  
contributes to the confusion of authors regarding suitable alt text.

I'm curious to here others thoughts on this.

Take care,
Rob

[1]: <http://interestingenergyfacts.blogspot.com/>