Re: an interoperable object (fallback and context menus)

Boris Zbarsky 2009-03-24 15.52:
> Leif Halvard Silli wrote:

    [ som snipping because the below answer most of it ]

>> On the other side: W.r.t. fallback, the problem is that both <object 
>> data="TIFF"> and <img src="TIFF"> are loaded via plug-ins in Firefox 
>> and Opera.
> 
> <img> is never handled via an NPAPI plug-in (which is what I assume you 
> meant above) in Firefox.  So I have no idea what you're talking about here.

Sorry, what I said seems to be true only for Opera.

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 were an error in what I said above. I believed that if you have 
>> this:
>>
>>     <object data="uri" ...> Text fallback 1.
>>           <object data="uri"> Text fallback 2.
>>     </object></object>
>>
>> Then only "Text fallback 2", as the innermost object, would constitute 
>> the textual fallback. But I now see that when looking at it from the 
>> textual fallback perspective, then the second object is more like a 
>> <source> element. (The only purpose of keeping the fallback in the 
>> innermost OBJECT is to hide it better from graphical UAs.)
> 
> Or because it's specific to the situation when neither of the two 
> formats is supported.

Verified for a tiff image (except in Safari 3):

http://www.malform.no/html5/object+nested,textual,fallback

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

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.

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.

I could also have mentioned the QuickTime Pro web video export - 
it too uses <embed>. And so on. For unclear reasons. QuickTime Pro 
  even places everything inside a <noscript> tags - had it not 
been for the noscript tags, textual fallback content of <object> 
would have floated outside the object element.

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


>> 2. Same issue if <img> is used as fallback.
> 
> Again, why?  Or are you talking about marked-up text, not just text?

Marked-up text.

> In any case, these are not issues with <object>, as far as I can see.

Only to the extent that expected behaviour is specified well enough.

>> Why *are* <embed> and <img> used as fallback - instead of adding a 
>>  second <object> as fallback? The answer is simple - at least when it 
>> comes to images: Because fallback to a second <object> is difficult to 
>> get to work. (Or is is it simply habit? I am not quite certain.)
> 
> The answer is even simpler: <object> inside <object> doesn't work at all 
> well in IE6.  In fact, it makes IE6 throw conniptions, last I checked. 
> Which is why the pattern people settled on was an outer <object> with an 
> ActiveX @classid for IE, and an inner <embed> for other browsers.  I 
> can't speak to the state of IE7 support for <object> inside <object>; I 
> assume the situation is much better in IE8.


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. (I cannot see why Youtube or 
QuickTime should not be able to do such tricks.)

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

>> (Though one could also dicuss treating <embed> effectively a <source> 
>> element, like Safari does.)
> 
> I'd be interested in seeing a testcase for this, for what it's worth.

The last example above demonstrates this - but here is another one:

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

>> Together with author practises. However "browser bugs" is a broad 
>> term. Those who are pusing <embed> as part of <object> are working 
>> against the fallback features of <object>.
> 
> Not sure what that last sentence is about.  Pushing in terms of content 
> they author?  Or the spec?  Or something else?

Both.

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

More generally, <embed> only takes away attention from <object> 
(as well as from <video> and <audio>).  It isn't logical when Ian 
argues against adding inline <d> (dialog) elements, claiming that 
they will be used too little (so little that no correct use 
tradition will materialize), and at the same time keep this 
pletora of embedding elements alive..

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


>> MIME was the first thing I tried. The draft says that if the object 
>> has a @type that begins with the 5 characters "image/", then the UA 
>> should perform image sniffing.  So there doesn't seem to be much room 
>> for MIME to have any role.
> 
> That might be worth changing in the draft then, especially if there are 
> multiple MIME types that all look the same to image sniffing.

Indeed!

>>> All that already works fine for _new_ file formats.  The PNG issue is 
>>> that a new format was created, but always claims to be the same as an 
>>> old format.  That's just poor format design, imo.
>>
>> I guess we must say the same about animated GIFs also then? (Since, 
>> when we get more animated image formats, one would like animated 
>> images to fallback to other animated images.)
> 
> Seems likely, yes.
 >
>> So what to do? Register new mimetypes? Plus change what HTML 5 says 
>> about looking at "image/"?
> 
> That seems like the most reasonable way forward to me, yes.  Note that 
> an option to registering new types is changing existing type 
> registrations to allow parameters indicating something additional about 
> the image.

This is certainly a good proposal. I hope we could get something 
like that done! But, as with registration of about:uri and other 
things that this group cares about, such a think would happen 
sooner and faster with some kind of manadate from the group to 
make it happen.

>>> Is that a MUST in 2119 terms?  Or something else?  Are you expecting 
>>> a browser to somehow know whether there are bugs in various dynamic 
>>> libraries it's linking to?
>>
>> No, not about bugs. Of course, we risk that an UA is classified as 
>> supporting, but still doesn't support fallback, as speficied.
> 
> Huh?

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.

>>>>>> - whether it is acceptable that the UA treats the resource as
>>>>>>   something else than what it is specfied to be.
>>>>>
>>>>> "specified" where?
>>>>
>>>> I had in mind that IE and Safari under certain circumstances 
>>>> presents <object> content as a frame because they think the content 
>>>> is a web page even when it is an image.
>>>
>>> That's just a bug, no?  I believe that there was a post earlier in 
>>> this thread linking to the relevant Safari bug reports.
>>
>> Sure, that was a bug. But you know that CSS is used to hide bugs. So 
>> that is not a contradiction, IMHO.
> 
> I have no idea how CSS just came into this, or what you're trying to 
> say.  Of course there's no "contradiction".  There's just buggy behavior 
> in some UAs, which needs to be fixed.  They're working on fixing it. 
> There's no need to make spec changes to deal with it, therefore.

I'm dropping my keyword idea - aka "CSS" idea - in favour of 
better MIME support. So no need to explain what I meant.

>>> I just think that this is the wrong way to approach the problem, 
>>> since any set will be too limited for some people, and since you 
>>> _still_ have buggy libraries claiming to support stuff that they 
>>> don't... from someone's point of view.  E.g. maybe they support 8-bit 
>>> alpha in PNGs in some cases, but not others...
>>
>> OK. But then, what do you suggest? A special MIME for 8-bit alpha PNGs?
> 
> Since the original definition of PNG includes 8-bit alpha, no.  Not 
> dealing with that is just a UA bug.
> 
>> 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?

>> Not unless the OBJECT algorithm changes, at least. The change one 
>> could introduce could be to say that before trying plug-ins (and the 
>> UA must find it's own definition fo that - but I think we coul agree 
>> in general)
> 
> I'm not sure about that.
> 
> 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.

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

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

>  From the perspective of Firefox, the latter looks identical to the 
> "built in" image handling code.

Sounds good. And clearly, Firefox appears most "after my heart" in 
this regard.

>> the UA should try the nested OBJECT, if there is any and if contains 
>> an image. If there were such an image attribute that you talked about, 
>> this could be simpler, may be.
> 
> This is pretty complicated in general.  For starters, "the nested 
> OBJECT" is not at all clear in the following markup:
> 
>   <object data="x">  <!-- video, say -->
>     <object data="y"> <!-- animated image -->
>     </object>
>     <object data="z"> <!-- audio file -->
>     </object>
>     <div id="control-panel">
>       <!-- some controls for affecting animation of the image,
>            controls for controlling the playing of the sound,
>            script to sync the two to each other, etc -->
>     </div>
>   </object>
> 
> I realize you only care about the image case, and only the case when the 
> fallback content doesn't contain anything other than a single <object>, 
> but I think that that case is better addressed by just fixing UA bugs.

I do not /only/ care about images. But I agree that if we fix the 
draft, fix the UA bugs and fix the RFC MIME shortcomings, then we 
should make progress!
-- 
leif halvard silli

Received on Wednesday, 25 March 2009 14:27:12 UTC