Re: an interoperable object (fallback and context menus)

Leif Halvard Silli wrote:
> However, there is a bug in Firefox for Mac with regard to TIFF, though, 
> as Firefox fails to display fallback for TIFF images on Mac (but not on 
> Windows) - both in current release and in 3.1 beta:
> 
> http://www.malform.no/html5/object+tiff

There's a plug-in that can handle that MIME type (QuickTime) to be 
exact, so it's instantiated.  But NPAPI doesn't have a way to 
communicate intrinsic sizes, and you didn't specify a size, so it ends 
up sized 0x0.  See discussion with Robert Burns earlier in this thread.

> But when <object> contains an <embed>, the story is different. Look at 
> the below test case. For the 4 first videos, the outer object is always 
> the same, and the inner object, when used, is also always the same. The 
> only difference is the presence - or not - of <embed>. But still Opera 
> actually *prefers* <embed> over <object>, *even when* it is able to 
> understand <object>. It even prefers the nested <object> in the second 
> video - over the outer object, even if it understands both.
> 
> http://www.malform.no/html5/object+youtube+nested,textual,fallback.html

In that testcase, the outer object has no @data and no @type and no 
@classid, so I'm rather surprised any browser at all instantiates the 
Flash plug-in for that outer object; there is nothing to load and no 
type specified, so it seems like the right behavior should be to just 
fall back immediately.

Presumably whatever heuristic they use to actually instantiate something 
is also what causes your issues with <embed>.  This behavior is 
certainly not the one called for by either HTML4 or the current HTML5 draft.

> Further more, in the two last video examples, which are taken straight 
> out of what Youtube offers as embedding code, the  outer <object> isn't 
> used in any of the browsers I have availble - all use <embed> instead.

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.

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

>>> 1. Embed being used as "the fallback" = hinders that textual fallback 
>>> can be added withotu disturing sighted users (unless one fiddles with 
>>> CSS).
>>
>> I have no idea why this would be the case...
> 
> ... above you explained why.
> 
> The non-standard tradition of using <embed> means that
> 
> a) one circumvent OBJECT, thus making everything inside <object> 
> available to all users of a conforming browser,
> 
> b) this will for certain confuse authors, who often copy-paste code, 
> when they see that all the fallback becomes visible.

To be honest, I have no idea what you're talking about here...

> It is perfectly possible to embed two object elements in each other in 
> Internet Explorer 6 - both as an outer object or as an inner object. It 
> takes tricks.

Which makes it more complex than object+embed, so people took the path 
of least resistance.

> (I cannot see why Youtube or QuickTime should not be able 
> to do such tricks.)

Because whoever wrote the code had seen the object+embed pattern everywhere?

> The general trick is to hide the inner <object> for IE6, and there is is 
> million ways to hide things for IE6. (I am not certain if managing to 
> target the inner object with a display:none is enough - will it cause 
> the video to be loaded twice in IE6?)

Last I checked, the issues were on the parser level, not just on the 
display level, so CSS couldn't really help.  But it's been a while.  In 
any case, the precise failure mode of IE6 here doesn't seem to matter 
for purposes of figuring out what the spec should say, to me.

> http://www.malform.no/html5/object+youtube
> 
> In the two first examples, Safari should have displayed the fallback. 
> But it doesn't. IE also doesn't - but unlike Safari it doesn't hide the 
> outer <object>.

Very interesting.  I'd love for someone who knows what's going on there 
to comment.

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

> More generally, <embed> only takes away attention from <object> (as well 
> as from <video> and <audio>).

That's an argument for making <embed> use non-conformant period, no? 
That is, defining processing, but making any page that uses it not validate.

> Where is that poster child of a web browser that is unable to handle 
> <object>?

The problem is that it's impossible to create an <object> that will work 
in both IE7 and, say, Gecko, last I checked.  The former requires an 
@classid, last I checked, while the latter will fallback if it sees one. 
  One can use nested <object> to get around this, but an <embed> will 
Just Work across the board.

So in fact, it's not that browsers can't handle <object>; it's that they 
handle it in such wildly different ways that using it in practice is a 
huge pain.

As IE7 and earlier disappears from use, the situation will change, I 
hope.  At least assuming IE8 does dispatch by type for <object>.

> Some sort of check I would eventually have expected - just as I expect 
> that one allready check MIME support. As for plug-ins, UA vendors could 
> have "plug-in guidelines" which specified that a plug-in that handle 
> PNGs also should be able to display transparent PNGs.

That would basically do nothing to affect plug-in behavior, unless UAs 
blacklisted plug-ins that violate the guidelines or something...  The 
whole point of plug-in architectures is to be a generic extensibility 
point: to allow someone else to do whatever they want.

>>> So then we are left with what we have: MIME and @classid. Classid is 
>>> possible to use, at least in IE, to some extent. MIME has some, but 
>>> limited use. For the common formats, JPEG, GIF, PNG, I don't see that 
>>> it has any use (by use I mean fallback use).
>>
>> As currently set up, correct.
> 
> Will you be offering a proposal for betterment?

No, sorry.  Not a high priority for me.

>> Seriously, from your perspective as a web author, is there a 
>> difference between an NPAPI plug-in that doesn't handle the type well 
>> and a Firefox extension that doesn't handle the type well?
> 
> No. But I have yet to find a plug-in that that presents transparent PNGs 
> as transparent, whether in IE or any other UA.

This should be pretty straightforward to do with a windowless NPAPI 
plug-in.  If a plug-in is not doing that (e.g. Quicktime on Mac; I just 
checked) then it's just buggy...

> But apart from that, do you agree that in case of
> 
>   <object data="IMG.JPG"> Text 1.
>       <object type="IN/VALID" data="IMG.GIF">Text 2.
>           <img src="IMG.PNG" alt="Text 3."></object></object>
> 
> then, if "IMG.JPG" was unavailable, while the "IMG.GIF" was available 
> but had a meaningless MIME type, then "IMG.GIF" should be displayed 
> still? (Since the value in @type should not affect the MIME header that 
> the server - due to the .gif suffix - is sending to the UA.)

In this case, a UA would be perfectly allowed to fall back from the 
inner object to the <img> without trying to load IMG.GIF.  While the 
HTTP header does trump @type, if @type is not supported then making an 
HTTP request is not required.  So one never even sees the HTTP header.

> But is this the case in real life? The answer is that Firefox and Opera 
> do. While Safari and IE displays the image instead:
> 
> http://www.malform.no/html5/object+image-fallback.html

Yep.  Both behaviors are allowed by the spec.  See the definition of 
@type on <object>.  Note that the above document is non-conformant, for 
what it's worth (due to a mismatch between the @type and the HTTP 
header).  In a conformant document this situation does not arise.

I make no guarantees about Gecko's future behavior in this regard; we 
might start looking at @type in terms of deciding whether to fall back.

-Boris

Received on Wednesday, 25 March 2009 15:32:50 UTC