- From: Leif Halvard Silli <lhs@malform.no>
- Date: Thu, 19 Mar 2009 01:47:53 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Robert J Burns <rob@robburns.com>, "L. David Baron" <dbaron@dbaron.org>, Boris Zbarsky <bzbarsky@mit.edu>, HTMLWG <public-html@w3.org>
Maciej Stachowiak 2009-03-18 21.46: Thanks for the clarifications. > 1) <object data="objectImage"> > --> In this case WebKit treats the <object> as a frame In fact, iCab offers a context menu for frames for that <object>. > 2) <object type="image/png" data="objectImage"> > --> In this case, WebKit treats the <object> as an image (natively not > via QuickTime) but our code for this does not offer context menus or the > ability to drag the image, as it would for <img>. This is another WebKit > bug. Setting @type to "image/GIF" gives same result (<object type="image/GIF" data="objectImage">) - it is like Webkit sees type="image/aKnownImageType" as a "please sniff" signal. To not make this too Webkit focused: 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"? I would perhaps expect that the UA would display the fallback instead. But this is not what is happening in Webkit. It is problematic that UAs try to display things they are incapable of. In such cases the author may like to serve some fallback that he knows the UA can handle. > I don't believe there is a bug on this yet. [...] (If isn't filed till I get the time do so, I'll do it.) > If you have cases where QuickTime is used to display an image instead of > native rendering, that would be a bug as well. I noticed that in Firefox 2, QuickTime was handling the <object data="objectImage"> case, hence I concluded ... -- leif halvard silli
Received on Thursday, 19 March 2009 00:48:43 UTC