Re: an interoperable object (fallback and context menus)

Boris Zbarsky 2009-03-19 16.59:
> Leif Halvard Silli wrote:

>> - while Opera and Firefoz do not. Created new test case to demo this 
>> [1]. This is not interoperable.

> I might be OK with implementing the IE/Safari behavior in Gecko, but is 
> it used for all types, or is it limited to images?

The issue requires more investigation first - it is safer to make 
IE and Safari behave like Firefox and Opera in this case ...

> I thought we were talking about <object> here.  <video> is a totally 
> different kettle of fish.

Same fallback expectations.

>> What if one UA supports one format - but badly, how do authors get the 
>> UA to serve the fallback instead? 
> 
> That's a problem in general, no?  Doesn't seem to be <object>-specific.

This is one of the spesific difficulties when using images with 
<object>.

> If your problem is that the author wants different preference orders for 
> different browsers, then you just won't be able to use static content to 
> express that; that's an issue with any fallback model that doesn't allow 
> explicitly targeting specific browsers in the markup, no?

Another way is to say that Web browsers fail to know what they 
support. Like for JavaScript sniffing, the sniffing should look at 
the supported features - and not look at the UA ID.

Problems with <object>:
   1. otherwise supported formats aren't (well enough)
      supported when using <object>,
   2. for unsupported formats, all kinds of effects are
      killing/competing with the fallback *feature*.

E.g. both Opera and Firefox 3 know that they do not support 
image/tiff, but instead of doing fallback, they hand the file over 
to quicktime - preventing the author from getting the fallback 
displayed. This beavior is excellent for elements that do not 
support fallback - such as <img>. But when Firefox treats <object 
data="tiff"> the same way, then it defeats the idea of how 
<object> - or fallback - is supposed to work.

Even if UAs should give the same user experience regardless of 
whether the image is inside <object> or <img> (same interface to 
them), they should still be treated differently when it comes to 
fallback. Or else <img> is a very fine element ...

>> Opera supports (or at least planned to support) animated PNGs. It 
>> would be nice to be able to serve such PNGs to Opera while at the same 
>> time serving GIF to those that do not support it.
> 
> Well... if there were a separate MIME type for animated PNG, you could 
> do this with content negotiation.  This seems like a poster child 
> example of it, in fact.

Cliches and deaf ears ...

>Too bad there is no separate type.

Which makes it very similar to the transparency support issue for 
PNGs. Both animated PNGs and transparency in PNG requires 
something other than MIME. An animation flag in an attribute? A 
transparency flag attribute?

How can negotiation work when sniffing takes over? Or when the 
plug-in kills the fallback feature - even when the MIME differs?

Let Opera and Firefox handle <img src="TIFF"> via QuickTime *at 
fallback level*. But not in the first level of <object> - when 
there is fallbak!

I am curious to see how this will look like for <video>: when the 
UA doesn't support the preferred format natively - but still 
supports it via a plug-in, while a native format appars in a 
nested <video> element. What happens then?

A better fallback model could allow users to specify

- whether UA should count in plug-in support when it looks at
   whether it supports the resource or not.
- whether it is acceptable that the UA treats the resource as
   something else than what it is specfied to be.
- whether lack of support for a particular resource feature
   (such as transparencey) should lead to fallback.
- whether an XML error in should lead to fallback or parsing
   errors being displayed or lead to fallback.

Better fallback requires that fallback is governed by more than 
MIME and URIs. Authors must also be able to specify the resource 
features that one are after - so the UA can go for fallback if it 
doesn't support those features.

For instance, if I could tell IE and Webkit that I do not accept 
frames as content of <object>, then I suppose that image  of the 
<object> would not be displayed if the only way Webkit or IE would 
perceive that particualar image was as a frame.
-- 
leif halvard silli

Received on Friday, 20 March 2009 05:34:12 UTC