[html4all] Object element support

Leif Halvard Silli lhs at malform.no
Wed Aug 20 04:13:54 PDT 2008


Jason White 2008-08-20 03.03:

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


Rob's reply had me thinking that what I dubbed as short vs long, 
should perhaps rather be seen as "plain text, likely quite short" 
versus "markup, optionally long".

The thing is: You have some preknowledge about what the @alt text 
is - its quality. You, in fact, also know that the @longdesc 
resource is adequate for non-sighted readers, because its purpose 
is to cater for those who can't access the image as image - for 
whatever reaason (technical or otherwise).

Wheras for OBJECT, how do you know for whom the alternative(s) 
is/are made? There is no such guarantee.

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


I don't subscribe to "semantically unrelated" - how can you know 
that? However, I agree that there is nothing which 
formally/technically binds the link to the precedign IMG, and thus 
neither is the target of the link formally connected to the IMG.

  

As for your interpretation of the link within the OBJECT, I 
disagree there as well. Because, what make the nested OBJECT 
related to the parent OBJECT, is the fact that it is nested, and 
the fact that  nested OBJECTs are defined in HTML 4 as being 
alternatives.

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

But @title also has defined meanings. I know of no other case were 
@title isn't supposed to be some kind of a title. (And, if, as you 
say, there is no need for short vs long, there would be no need 
for it either.)

I am lost with regarod to your point about "confusion".

Also, @longdesc /is/ a link. That is why proposed it.

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


Sorry, 'you are saying' was supposed to mean 'one are 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.

There is no disagreement between us regarding the advantage of 
being able to insert mark-up as fallback in the OBJECT.

But as you know, limitatations are not always bad. They can 
sometime force us to do some good things which otherwise perhaps 
would not have come naturally - make us creative. So, e.g. if I 
run an IMG without an @alt in the validator, then it cries. 
Whereas if I insert an OBJECT without a fallback, then there is no 
cries, not even a warning. And I can even let a flash movie fall 
back to QuickTime instead of text. And still no cries.

Clearly, if the question of fallback was linked to @role rather 
than the kind of element - IMG or OBJECT in this case, then the 
validator could prompt for the addition of textual fallback 
(markup or plain text - how about MathML, screen readers ... ?).

But even then, there would have to be rules for what to place 
there. And how to place it. And how the user should get/select/be 
served /his/ fallback. (How do you place a link to the textual 
fallback in a QuickTime movie?) Today, following the rule of 
'graceful degradation', an OBJECT with a movie would contain 
"advanced movie format" in the first OBJECT, and a "not so 
advanced movie format" would come in the second OBJECT. Then 
perhaps you'd find plain text/markup in the third level. But 
perhaps the text level fallback should come in the second level?

Also, here is a nuisance: What should happen if the OBJECT is a 
movie, and the fallback is markup in the form of an IMG element, 
and then - in adddition, a second OBJECT has textual fallback?

	<object data=movie.mov >
	<img src=src alt=alt >
	<object><p>mark-up
	</p></object></object>

We would then get two conflicting fallback-regimes: That of the 
IMG and that of the OBJECT. It cold  at least end up very 
confusing. Perhaps the screen reader would read the @alt, and miss 
the presence of "a better alt" in the nested OBJECT? What should 
the rules for the use of IMG inside OBJECT be?

The combination of IMG, @alt, @longdesc, is like a microformat 
that has developed over time, with quite firm rules. OBJECT might 
be superior. But this has not been put into practise. As massive 
jump to OBJECT could have lead to a drop in accessibility due to 
lack of actual, practical advice and tradition (that authors are 
aware of) for how to use it.
-- 
leif halvard silli



More information about the List_HTML4all.org mailing list