Re: an interoperable object (fallback and context menus)

Leif Halvard Silli wrote:
>> Yes.  But the desire to fall back to a different type of content 
>> altogether for an <object>, in preference to handling the type of 
>> content the author prefers but with a plug-in, doesn't seem common.  
>> For the most part, those who are in that position just use the more 
>> broadly implemented content format to start with.
> 
> Hm - well, I would not say that: When serving "moving images" via 
> <object>, the trouble is that some UAs needs <embed> instead. And so an 
> <embed> is nested inside <object>. Wheras for <object>, the trouble is 
> that some needs <img> instead, which could be inserted as fallback. 
> Quite similar.

OK.  So what's the issue, exactly?

> To me, the two isssues are connected: The most basic thing is that it is 
> simple to use <object>. With IE8 it is actually starting to become 
> simple. But it should also have been simple to take advantage of the 
> fallback - without it, it becomes difficult to take advantage of the 
> simplicity that IE8 brings.

It _is_ simple to take advantage of the fallback.  You serve your 
content, and if the UA can't render it it falls back.  You're suggesting 
making that much more complicated, from what I can see.

>>> Of course: IMG do not allow same media fallback. That's the 
>>> difference. And that is also why it is logical that <img> loads the 
>>> image via plug-in.
>>
>> I'm not sure what that last sentence is saying.
> 
> For <img src="TIFF" alt="Txt."> it is likely better to try to render the 
> image, even in some mediocre quality, than it would do the same for this 
> OBJECT to use the same mediocre plug-in:
> 
> <object data="TIFF">
>     <object data="JPG">[Txt fallback]</object></object>

"quality" is a subjective thing (as is "mediocre").  At what "quality", 
exactly, should fallback to the data="JPG" object occur here?  Right now 
the cutoff is a self-reported "any support at all"; any other cutoff is 
hard to define.

>>> Sure. :-) But <object> becomes superfluos - from a graphical media 
>>> point of view - if it just duplicates how <img> behaves with regard 
>>> to loading plug-ins.
>>
>> Um.  Except of course that it precisely does NOT do that right now. 
>> Your whole problem is that it doesn't, as far as I can tell.
> 
> One one side: In Internet Explorer (until version 8) and (to a much 
> lesser degree) Safari, the problem is that images served with <object> 
> are not giving  users the same experience as images served with <img>.

That's a UA bug, not a spec issue.

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

> Thus neither author or user get to experience the fallback advantage that OBJECT is supposed to have.

The fallback for object is something that happens if the data cannot be 
shown.  In this case it can be shown.  Apparently your issue is that the 
code doing the showing doesn't show it as well as you'd like; this would 
be an issue regardless of whether it's a plug-in being used to handle 
the data (e.g. IE6 and PNGs with 8-bit alpha).

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

> Thus, having said that, you should understand the paragraphs you asked 
> about above better: Uf the fallback of the <object> is an <img>, then 
> the <img> a) requires an alt="", b) the alt has very little room for 
> fallback, c) if you place text outside the <img>, as a child of the 
> <object>, then even GUI browsers will display that content (unless - of 
> course, you apply some CSS).

OK.  Why is that a problem?

> That was the entire point. Letting <object> fall back to an <img> is not optimal use of <object>.

Sure, unless you're targeting UAs with no <object> support at all.

> There is the same problem with letting <object> fall back to <embed>: 
> You cannot add fallback text, or else the fallback text will "spill 
> over" - at least in Firefox and Opera (which follows the spec (HTML 4) 
> and the draft (HTML 5).

You mean fallback text for the <embed> itself?  Or something else?  Not 
sure what the point is here.

> Safari has taken a differnt approach - it seems - where it uses the 
> <embed> element more as if it was a <source> element. Thus it hides the 
> content of <object>. The Safari behaviour makes some sense - it is 
> easier to author with.

How, exactly?

>> What about it doesn't work exactly?  You serve media of a particular 
>> type; the browser tries its best to render media of that type.  If it 
>> can't, it falls back.  You want it to try less hard, as far as I can 
>> tell.
> 
> Yes. I would like the UA to try less hard when the <object> contains 
> another <object> which also contains an image.

Ignoring for the moment that this is not trivial to determine, this 
leaves the issue of defining "how hard".  I don't see a good solution to 
that.

It seems the time and effort would be better spent fixing the bugs that 
make you want the UA to try less hard.

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

> 2. Same issue if <img> is used as fallback.

Again, why?  Or are you talking about marked-up text, not just text?

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

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

> So, with the choice you gives me, the problem is browser bugs. 

Then the solution is fixing them.

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

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

>> Other than the phrase "poster child", which part was a cliche, exactly?
> 
> Nothing. That was the cliche.

So in other words you decide to ignore everything else I said because I 
used that phrase?

I wonder why I'm even bothering with this discussion.

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

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

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

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

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

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

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

-Boris

Received on Tuesday, 24 March 2009 14:54:19 UTC