I think you misunderstood what I was saying (or I didn't present it 
well, which is more likely).

It is important to break backwards compatibility in this case, because 
of an existing bug. If IE won't try to render it, it will move on to the 
fallback. The beauty of <object> is that it allows for multiple nested 
"fallbacks" if the browser can't handle the top level object. So you can 
do this (really rough example, tabs are for clarity):

<object data="test.png">
	<object data="test.jpg">
		<img src="test.gif" alt="Test Picture" />
	</object>
</object>

In this situation, the rendering engine will try to load the PNG first. 
If it doesn't understand/know what it is, it move on to the JPEG. If it 
still can't load it, doesn't understand the file format, or doesn't know 
what <object> is, it will load the GIF (with the ALT text as a further 
fallback).

The problem, like I said, isn't browsers that don't understand <object>, 
because they will move on to the backup. The problem is idiot browsers 
like IE, that can't render it properly but think that they can. 
Switching to <obj> would solve this problem, since IE would go to the 
<img> tag, and you would still have valid XHTML 2.

Jason


Christoph Päper wrote:

> Jason M. Kikta <kiktajm@muohio.edu>:
> 
>>The most important thing is to break backwards-
>>compatibility with <object>. This is a smart move,
> 
> 
> I don't think so. To break backwards compatibility if required, is okay for
> XHTML2, but to break it just to break it, is just dumb.
> 
> 
>>IE is so horribly broken in this respect,
> 
> 
> IE, at least the Windows version, doesn't even try to support XHTML yet, let
> alone XHTML2. So why change anything of the spec based on pure assumptions
> of future bugs in future browser versions?
> 
>