Re: an interoperable object (fallback and context menus)

Leif Halvard Silli wrote:
> So we must wait for a plug-in api fix, I gather.

Yep.

>> I can't help the fact that Youtube is suggesting silly markup; as far 
>> as I can tell all those browsers have the right behavior.
> 
> You can support removing <embed> from HTML 5.

I could, but I'm not really convinced it's harmful...  That said, you 
might want to bring up this suggestion in a separate post.  I get the 
feel this thread is not getting widely read.  ;)

>>> So the mania about always using embed seems to be based on 
>>> superstition and tradition - not on what UAs support or can be made 
>>> to support.
>>
>> As long as you don't have to worry about older IE releases, I believe 
>> this is correct.
> 
> So why do we keep it?

Good question; worth asking explicitly.

>>>>> 1. Embed being used as "the fallback" = hinders that textual 
>>>>> fallback can be added withotu disturing sighted users (unless one 
>>>>> fiddles with CSS).   [...]
> 
>> To be honest, I have no idea what you're talking about here...
> 
> http://www.malform.no/html5/object+youtube
> 
> As the two first examples of that page demonstrates: When an UA falls 
> back to <embed>, then any textual fallback - like a transcript or image 
> description - will also by neccessity become visible. This we agree 
> about as correct behaviour.

Yes.

> We also agree that fallback should only show when the intended resource 
> fails to load.

Or is of a type the UA can't handle, yes.

> And we know that for the <object><embed> pattern, the intention is to 
> show the fallback, because <embed> is the fallback.

The fallack is the contents of the <object> whatever it is.

> We also know that this pattern isn't use because one has corresponding 
> fallback text.

This part I don't follow.

> My claim, then, is that the <object><embed> pattern has a negative 
> effect on authors' and developers' perception of what <object> can do 
> and how it works. (We have some evidence of this confusion, for example 
> the Safari treatment of <object><embed> - see below.)

I agree that Safari's behavior here is wacky.

> Only that day when an author needs to include some fallback text, will 
> he get to experience that it doesn't work together with <embed>.

How does it not work, pray tell me?  Seems like it works fine, except in 
Safari.

> It would be better to use a bare naked <embed> than to clad it in an 
> <object>. After all, IE seem to have support for <embed> as well (I 
> don't know to what extent.)

This doesn't give as much control in some cases (e.g. Flash, where there 
are various <param>s you can use with <object>).  Which is why people 
use <object> for Flash in IE...  I suspect most other <object> usage is 
colored by the Flash situation, since Flash is so commonly used.

>> Which makes it more complex than object+embed, so people took the path 
>> of least resistance.
> 
> The path of least resistance or just the most common path?

The former automatically becomes the latter.  In this case, I think we 
had the former.

>>> One thing is <embed> in itself. But it should at least be invalid to 
>>> use <embed> inside <object>. Or, at the very least, it suld be 
>>> forbidden to use it as the single fallback of an <object>.
>>
>> Why, exactly?
> 
> Was the explanation above satisfying?

Not completely; again, this would be a good subject for a separate thread.

> I think we are past those days when one must do this in order to support 
> both IE and other browsers simultaneously. And to continue to allow this 
> only only adds to the confusion about how <object> works with regard to 
> fallback.

That's a somewhat compelling argument, yes.

-Boris

Received on Thursday, 26 March 2009 16:06:06 UTC