Re: an interoperable object (fallback and context menus)

Leif Halvard Silli wrote:
>> That said, what it means in practice is that the UA will hand it over 
>> to its image library which will proceed to sniff the magic number of 
>> the image.
> 
> Thus in reality, UAs ignore the HTTP header, you say?

Once UAs determine that the content should be rendered as an image, they 
ignore the header in terms of deciding what exact image format it is.

You can test this by taking a PNG, serving it as image/jpeg, and 
pointing a browser to it directly.  Then note that if you change the 
type you send to text/html the data is no longer rendered as an image 
(in most browsers).

> So type="image/KnownImageFormat" = sniffing signal.

Sort of.  In Gecko, you'd have to get that in the HTTP headers (or no 
type at all, or application/octet-stream) for the type attribute to matter.

> However, Webkit and 
> Internet Explorer see type="image/UN-KnownImageFormat" as a fallback 
> signal

Which is allowed by the spec, yes.  If you don't know how to handle the 
type listed in @type, you're allowed to not fetch the resource at all 
(and then not see the HTTP header).  In fact, that's the only purpose of 
@type in the HTML4 spec.

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

While true, that's what happens when you have SHOULD-level requirements 
and conflicting metadata....

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?

>>> I would perhaps expect that the UA would display the fallback instead. 
>>
>> Er... why?
> 
> What is the criteria for when the fallback of <video> is used?

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

> If the UA must "try and see" first, then the fallback functionality becomes 
> increasingly more useless - or what?

I'm not sure what you're saying here.

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

> Via HTTP headers one can signal that one format is preferred - but what 
> one wants is to send different signals to different UAs. But if <object> 
> really is 3 nested <object>s, would signalling that the innermost 
> <object> contained the preferred format really help?
 >
> Ok - here, the subject really is side-effects of unknown MIME messages.

I'm still not sure what you're talking about, honestly...

> Ultimately, it is as if the fallback model is wrong. Currently UAs tries 
> to render the outer <OBJECT> first, and only thenafter try the fallback.

Right.

> It seems more fruitful if UAs would look at the fallback first, deciding 
> to not try the outer <object> at all if it seems to not support what it 
> contains.

Which "it" is what here?

In any case, the fallback model is quite straightforward:  the author 
lists the content he wants to serve up in the order he prefers it in, 
and the browser uses the first one in the list that it can handle.  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?

> 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.  Too bad there is no separate type.

-Boris

Received on Thursday, 19 March 2009 16:00:05 UTC