On Sun, 29 Jun 2003 15:47:48 -0400, Jason M. Kikta <kiktajm@muohio.edu> 
wrote:

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

I would be inclined to agree with Christoph in this case.  No user-agent 
can or should yet support XHTML 2.0 or even should for years to come, so I 
believe your argument, Jason, is mostly invalid, considering Microsoft is 
likely to eventually fix whatever bugs plague their <object> 
implementation.  However, I do feel that <object> should be shortened 
because it is six (not three as Mr. Meadowcroft stated, as <object> should 
never be an empty element) extra, largely unnecessary characters, each of 
which could lead to frustrating typographical errors. And, considering 
object nesting for alternative content and the fact that <object> will take 
on the role of <img/> as well as its current one, it will be used -quite- 
extensively.

Perhaps it is just a minor change that would only benefit a relatively 
small percentage of user/authors, but I am the kind of person who routinely 
muddles up <object> (and even <span>), and I don't see how shortening the 
element tag would have any major adverse effects.

(this should probably be more in reply to Ben Meadowcroft's mailing, but I 
was not subscribed to the list at the time he posted his reply, so I am 
unsure how to reply to it while keeping proper threading.  This will do, 
though.)

-- 
J.