[html4all] Object element support

[Robert J Burns]

Hi Leif,

On Aug 21, 2008, at 6:15 AM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-21 00.49:
>
>> On Aug 20, 2008, at 3:35 PM, Leif Halvard Silli wrote:
>
>
>>>     <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.
>>
>> Well it is still geared at screen readers as long as each bit of
>> embedded non-text media has some text fallback. In your example
>> everything is covered in terms of alt text / text equivalents.
>
>
> So you don't hink a validator should OK this?

No, I think the validator should throw an error for the IMG element.  
However, I'm saying everything is covered in terms of UA conformance.  
That is even though a document is in error following your example, the  
UA could still produce intelligible output for the user (I'm only  
saying in error for HTML5, though I think the prose of HTML4 also  
imply this is an error). It could be make to work, but I think it adds  
needless complications to permit it in document conformance.

>>> 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.
>>
>> Yeah, I think you're partially right. I took a look at the HTML 4.01
>> prose[1] and DTD[2] and the DTD fails to give unambiguous normative
>> guidance on precisely how this should work. The prose on the other  
>> hand
>> do explain it, but there could still be some ambiguities that I'm
>> missing. It doesn't have the normative language that the HTML5 draft
>> should include. It should be made clear that every object element  
>> should
>> include an ultimate fallback object element containing FLOW content
>> minus any other embedded non-text media elements. (IMG, CANVAS,  
>> APPLET,
>> EMBED, VIDEO, AUDIO, OBJECT).
>>
>
>> I think your example is still a bit unorthodox however, since  
>> normally
>> the content model should be (PARAM* , OBJECT) or (PARAM* ,  
>> (&flow;)* -
>> [embedded media elements]).
>
>
> HTML 4 does not preclue the inclusion of IMG amongst the flow
> elemements. In fact, IMG is also flow. As is OBJECT itself. (As
> you yourself note .)

It doesn't in the DTD, but I think the prose imply this is non- 
conforming. Again, I think the prose implies this is non-conforming,  
but it is not stated clearly enough for my taste.

>> In other words either object fallback or
>> flow fallback with no embedding. I think the conformance checker  
>> should
>> check for this. And in cases other than role='decorative', the
>> conformance checker should throw errors for missing text fallback (or
>> throw warning for role='photo').
>
>
> Perhaps a warning if the flow contains an IMG. But not an error,
> unless the fallback of the IMG itself is used wrong. Why shouldn't
> embedded not-text elements be permitted,  provided they contain
> fallback themselves?
>
> I also wonder whether <objeect type="text/html" .... > should be
> equal to the requirement of text fallback?

or 'text/plain', or even 'text/rtf'. For these I think the validator  
should throw warnings only. After all text/plain could even be ascii  
art (just as one example) and still require either object alt text or  
longdesc. Also since the author of the present document may have no  
control over the accessibility of the embedded documents, the author  
may need to include the appropriate alt text and other text  
equivalents in the primary document.

>
>
>> BTW, further reflection on your earlier quote form the Microsoft IE
>> Blog[3], leaves me a little stunned if this is actually true. Does
>> anyone have IE (any version) handy to test this? As Leif quoted  
>> earlier:
>>
>> "<OBJECT> is not parsed in a cross-browser compatible way (parsing  
>> stops
>> at the OBJECT, whereas other browsers continue parsing all the  
>> fallback
>> content and make it available. No support for this parsing behavior  
>> is
>> planned for IE8; I'll take this opportunity to ask for real-world
>> scenarios that can help me prioritize this feature."
>
>>
>
>> I find it hard to believe that the content of the OBJECT element  
>> are not
>> parsed. Is it simply thrown away? Is it added to the DOM as plain  
>> text?
>> Or does it mean that the more sophisticated fallback mechanism  
>> enabled
>> by the OBJECT element is not supported so that IE simply handles only
>> the first embedded content and ignores the remaining content. Does IE
>> have a DOM browser like the other browsers? I guess you could always
>> view it at Hixie's DOM viewer[4]. If the tree of OBJECT elements is
>> shown properly nested with the fallback text in a text node within  
>> the
>> second object than the IE blog entry is incorrect
>
>
> IN IE 6 the statement seems correct. And after having installed
> IE8beta, it seems you are right in that it is not correct for IE8
> ... (Have not tried IE7, and do not trust the IE7 emulation of
> IE8.) However, a better test case than yours is this (since in
> your test, in IE8beta1, the GIF would actually be displayed):
>
> <object data="data:application/x-unknown,ERROR" >
> <object type="image/gif" data="object-ie8.gif" >
> some fallback</object></object
>
> Either they were wrong, or we misunderstands the issue ... I
> wonder if they mean that if an OBJECT with an working
> data="attribute" URI is found, then then the other nested OBJECTS
> and the rest of the fallback content is ignored.

Well, if an object is reached that IE can handle natively or through a  
plugin handler, then that is what the HTML4.01 recommendation expects.  
The issue is if you view the DOM, do you see the descendant nodes  
there. If so then a sophisticated add-on or screen reader (something  
like Fire Vox for example, though it is for Firefox) can get to the  
fallback for accessibility reasons. In other words the DOM should look  
something like:

HTML
	• HEAD
	• BODY
		• OBJECT data="data:application/x-unknown,ERROR"
			• #text:
			• OBJECT type="image/gif" data="object-ie8.gif"
				• #text: some fallback

If that's all there in IE, and IE selects the first supported or  
enabled mime type in hierarchical order, then that's all we would  
expect (since IE has no aural/braille features of its own).

Take care,
Rob