[html4all] Object element support

Robert J Burns rob at robburns.com
Wed Aug 20 15:49:28 PDT 2008


Hi Leif,

On Aug 20, 2008, at 3:35 PM, Leif Halvard Silli wrote:

> Robert J Burns 2008-08-20 13.46:
>>
>> On Aug 20, 2008, at 2:13 PM, Leif Halvard Silli wrote:
>>
>> 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.

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.

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

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]). 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').

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.

Take care,
Rob

[1]: <http://www.w3.org/TR/html4/struct/objects.html>
[2]: <http://www.w3.org/TR/html4/sgml/dtd.html>
[3]: See "Known issues we are not planning to change in IE8" in the  
official Internet Explorer blog. <http://blogs.msdn.com/ie/archive/2008/04/10/html-and-dom-standards-compliance-in-ie8-beta-1.aspx 
 >
[4]: <http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cobject%20data%3D'http%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fwww-archive%2F2007Aug%2Fatt-0027%2FTestVideo.3gp'%20%3E%0A%20%20%20%20%20%3Cobject%20data%3D'http%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fwww-archive%2F2007Aug%2Fatt-0026%2Fimage.gif'%20%3Esome%20fallback%3C%2Fobject%3E%0A%3C%2Fobject%3E 
 >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080821/6600323a/attachment.html 


More information about the List_HTML4all.org mailing list