[html4all] Object element support

[Leif Halvard Silli]

Robert J Burns 2008-08-20 13.46:

> Hi Leif,
> 
> On Aug 20, 2008, at 2:13 PM, Leif Halvard Silli wrote:
> 
>> 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".
> 
> Even this doesn't get to the distinction that I'm trying to make. Take  
> XHTML2 as an example. In XHTML2 all embedded media elements include  
> the possibility of rich markup text in their own element contents (no  
> need for an alt attribute). However, there is still a need for a  
> separate kind of text equivalent (usually facilitated by the longdesc  
> attribute) that is for description that is not alt text. In other  


Are you saying that @longdesc is used more or less as I proposed 
in XHTML 2? Or, at least, that they have extended its use there?

> words in XHTML2 (if it included a longdesc or aria:describedby  
> attribute) could provide 1) alt text as a replacement for in- 
> consumable non-text media and 2) a textual description for a more  
> detailed subject or visual description of that media not necessarily  
> as integral to the comprehension of the document as the alt text.
> 
> Now in this example, either can be long or short and either can be  
> plain text or marked up text. The distinction is not about that, but  
> rather how integral is this equivalent text to comprehending the  
> document. I hope that helps clear up the distinction I'm trying to  
> make. I think making a document truly accessible involves adding  
> either or both of these text equivalents.


If you say that e.g. OBJECT should have a rquirement of a textual 
fallabk, in a validate-able way, then we are en route.

[... snipped my OBJECT fallback problem description ... ]

> I think you raise some good points here, especially regarding the  
> OBJECT element's fallback and validator/conformance checking. Your  
> example convinces me that we should require some significant text  
> within the object element when the role keyword prescribes it.  
> Otherwise we do lose the accessibility awareness raising benefits of  
> the alt attribute.


Good to know.

 
> However, I don't think the use of the OBJECT element is as complicated  
> as you're making it out here. In other words the fallback semantics  
> are very well defined. So in your example:
> 
>> 	<object data=movie.mov >
>> 	<img src=src alt=alt >
>> 	<object><p>mark-up
>> 	</p></object></object>
> 
> 
> the IMG element element does not serve as another fallback level.  
> Rather both the IMG and the second OBJECT together form the fallback  
> for the initial OBJECT. Their can only be one fallback level once the  
> contents of an object includes anything other than an OBJECT or a  
> PARAM element. 



Hm. So, in that case, the nested OBJECT would instantiate an 
independent, /new/ OBJECT with its own fallback treatment, 
independent form the top-level OBJECt, then I guess:

  	<object data=one-movie.mov >
	<!-- all this is fallback for 'one movie': -->
  	<img src=src alt='Fallback for IMG, as part of
         fallback for one-movie.' >
  	<object  data=another-movie.mov >
	Fallback for 'another movie', which again is
         fallback for one-movie.
         <!-- end of fallback for 'one movie' -->
  	</p></object></object>

But this, then -- again -- illustrates how the fallback of OBJECT 
isn't geared at screen readers, as the fallback itself can contain 
both text and movies, simultanously.

> Your construction doesn't cause a validator flag, but I  
> think if definitely should. Or perhaps even two validator flags, one  
> because an OBJECT is included in the ultimate text fallback and also  
> because the IMG (another non-text media element) is included in the  
> ultimate text fallback of the OBJECT element. So the way OBJECT is  
> supposed to work (and maybe you're saying that the HTML 4.01  
> recommendation doesn't make this clear enough) is that the OBJECT  
> element can only contain 1) any number of PARAM child elements  
> followed by one OBJECT element or 2) any number of PARM elements  
> followed by FLOW content (but no OBJECT element).
> 
> I'll have to take a look at HTML 4.01 to see if this is explicit, but  
> HTML5 should definitely make this clear.

Must give this more thought. But I feel what you say suppports 
what I've said about how OBJECT is lacking an actual description 
of how it, in the "real world", is going to be used. There is to 
much high level "it is superior" thinking going on, without 
looking at the details of how it should be used, is my view.
-- 
leif halvard silli