W3C home > Mailing lists > Public > public-html@w3.org > March 2009

Re: an interoperable object (fallback and context menus)

From: Leif Halvard Silli <lhs@malform.no>
Date: Thu, 19 Mar 2009 12:03:10 +0100
Message-ID: <49C2266E.4000400@malform.no>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: HTMLWG <public-html@w3.org>
Boris Zbarsky 2009-03-19 02.11:
> Leif Halvard Silli wrote:
>> What is a UA supposed to do if the file suffix is ".png", the Web 
>> server also tells that the file is "image/png" - while the type 
>> attribute says "image/GIF"?
> 
> The type attribute and file suffix are irrelevant if the server sends a 
> type.  What matters is the HTTP header in this case.

Makes sense - it's like <meta> is overridden by server headers.

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

> If this is an image in a format supported by the UA, it'll get shown as 
> an image.

So type="image/KnownImageFormat" = sniffing signal. However, 
Webkit and Internet Explorer see type="image/UN-KnownImageFormat" 
as a fallback signal - while Opera and Firefoz do not. Created new 
test case to demo this [1]. This is not interoperable.

>> 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? If 
the UA must "try and see" first, then the fallback functionality 
becomes increasingly more useless - or what? What if one UA 
supports one format - but badly, how do authors get the UA to 
serve the fallback instead? 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.

For "compatibility with 'the Web'", it would be nice if there was 
a way to get old Internet Explorer versions to ignore <object> and 
use the fallback instead - without at the same time affecting the 
other browsers. (Ugly as it is, apart from Webkit, the new test 
case [1] shows that "type="image/Uknown" could have that effect - 
if IE8 and Webkit starts to behave like Opera and Firefox.)

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

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.

>> I noticed that in Firefox 2, QuickTime was handling the <object 
>> data="objectImage"> case, hence I concluded ...
> 
> Note that the <object> code in Gecko was rewritted after Firefox 2.

Allready recognized in that test. [2]

[1] http://www.malform.no/html5/object+image+type=unknown
[2] http://www.malform.no/html5/object
[3]
-- 
leif halvard silli
Received on Thursday, 19 March 2009 11:03:52 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:43 UTC