Re: an interoperable object (fallback and context menus)

Hello Maciej,

Maciej Stachowiak 2009-03-14 08.32:
> On Mar 13, 2009, at 7:25 PM, Robert J Burns wrote:
>> On Mar 13, 2009, at 4:15 PM, Maciej Stachowiak wrote:
>>> On Mar 13, 2009, at 12:39 PM, Boris Zbarsky wrote:
>>>
>>>> Maciej Stachowiak wrote:

>> Other parameters (many read/write) that would be useful to share 
>> between UA and plugins:
>>
>>  - contextual menu enhancement (where the UA creates the contextual 
>> menu but provides space for the plugin to add items as Leif's test 
>> demonstrate[1])
> 
> Creating context menus or time or volume controls for plugins is not 
> something we want to get into. Those are things that have traditionally 
> been the plugin's responsibility.

Message summary:

1. Webkit should fix how it handles OBJECT images in the
    single case when it *does* handle them on its own.
2. For the other cases, if Webkit can't ask QuickTime to
    a. ensure that users get contextual menus for OBJECT images
    b. and that users get fallback if the data URI fails,
    then Webkit ought to start handle such images on its own -
    like the other browsers seem to do.
3. If QuickTime *is* asked to improve, they should be told to:
    a. offer same/similar *image* context menus as Webkit;
    b. offer the HTML fallback if image URL is wrong (instead
       of that lousy questionmark that one currently gets).
4. Webkit may have a cool URI problem for images in general.

Video and other plug-ins are one thing - users are pretty used to 
differing interfaces for vidoes. But everything that <img> can 
handle, <object> should treat the same. /That/ was the original 
focus of this thread, including the original test page [1] - and 
also of the new Webkit biased test page [2]. (Chris should also 
look at that page despite its Webkit bias.)

(A) To get Webkit to deliver OBJECT images with context menus and 
fallback (the new test page - image 1 and 6 demonstrate the 
fallback issue [2]), authors must currently ensure that Webkit 
*doesn't* use the plug-in to load the image.  Possibly the 
fallback problem also affects Safari + VoiceOver?!

(B) To achieve the above, one must use <object data="Cool-URI">. 
That is: no  file suffix and also no (or possibly an unknown) MIME 
must be set by @type.

(C) In addition - to make it look nice - one must also set the 
object dimensions - which must be specified to exactly match the 
intrinsic size of the image. Or else, Webkit makes the image look 
like in IE6 and IE7 (or IE8 in quirks mode).

(E) The fallback problems when QuickTime takes care of the display 
really hints that there is something lacking w.r.t. to the 
undersanding/specification of how and when fallback is delivered - 
  especially w.r.t. the interaction of plug-in and browser.

(E) There seems also to be a problem with the handling of cool 
URIs for images in general - disregarding whether one uses <img> 
or <object> - which makes images with a cool URI load after the 
images with a direct URI. I do not seem to see this in Opera, 
Firefox. And also I do not see it in Safari 3/current iCab when 
QuickTime loads the images. (Safari 4 seem to handle the cool uri 
aspect better - but I don't know if this is due to a general speed 
bump or becuase I run it on a faster test computer.)

[1] http://www.malform.no/html5/object
[2] http://www.malform.no/html5/object+webkit
-- 
leif halvard silli

Received on Wednesday, 18 March 2009 20:16:35 UTC