Re: an interoperable object (fallback and context menus)

Leif Halvard Silli wrote:
>> I thought we were talking about <object> here.  <video> is a totally 
>> different kettle of fish.
> 
> Same fallback expectations.

Except the spec for <video> currently says that the fallback for <video> 
works completely differently.

So apparently at least some people have different 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>.

Sure.  But it's not limited to that special case.

> E.g. both Opera and Firefox 3 know that they do not support image/tiff

They do not support it with their image library.  The can render it 
using plug-ins, of course.  <object> does not specify a rendering 
method; it just asks to render the content; plug-ins are explicitly 
included in ways to render the content.  If the content cannot be 
rendered at all, you fall back.

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

You're supposed to fall back if you can't render the image.  The image 
is being shown.  Hence no fallback.

Now I realize your issue is that you want the UA to realize that the 
image is an image in this case and provide the appropriate context menu, 
etc.  So in fact, you would prefer that your fallback GIF be rendered by 
the UA to the TIFF being rendered by a plug-in.  This is by no means the 
most common use case with <object> however...  Perhaps we need an 
attribute (or set of attributes) on <object> that allows author control 
over the methods the UA uses for rendering the content?  Not sure what 
form this would take; a start here would be trying to figure out what 
the different rendering methods are and how one differentiates them.

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

They _are_ treated differently when it comes to fallback: <object> 
allows much richer fallback than <img>.

And <img> is in fact fine element.

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

I'm not sure what you're trying to say here.

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

That would break existing content (due to breaking how <object> works in 
HTML4).  As I said above I could see the need for a off-by-default flag 
authors could toggle to get this behavior.

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

Per current <video> spec, the outer <video> is rendered.  In fact, all 
content inside <video> is ignored by a UA that implements <video>, per 
current spec.

If this was a hypothetical question about some other proposal, I'd like 
to see the proposal; it's impossible to answer otherwise.

> A better fallback model could allow users to specify

Users or authors?

> - whether UA should count in plug-in support when it looks at
>   whether it supports the resource or not.

Define "plug-in"?

> - whether it is acceptable that the UA treats the resource as
>   something else than what it is specfied to be.

"specified" where?

> - whether lack of support for a particular resource feature
>   (such as transparencey) should lead to fallback.

This involves enumerating all possible features of all possible 
resources?  Or something else?

> - whether an XML error in should lead to fallback or parsing
>   errors being displayed or lead to fallback.

This sentence seems to have gotten mangled.  Not sure what it was trying 
to say.

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

This is very difficult to do across the space of all possible content...

-Boris

Received on Sunday, 22 March 2009 19:02:36 UTC