Re: an interoperable object (fallback and context menus)

Robert J Burns wrote:
> There may be no single reasonable dimension to assume, but I would 
> suggest that since video is inherently spatial that 0x0 is a 
> indisputably an unreasonable dimension to assume.

Well, hold on.  How do I know it's video?  All I know (as a web browser 
engine here, not a human capable of passing a Turing test) is it's a 
type I don't know how to handle and that I should hand it over to a 
plug-in.  I could hardcode the flash type, but that would just break 
other, less popular, plug-ins because sites would assume they don't need 
to give a size for flash, so they don't have to give a size for anything 
else.  The MIME type in this case is not video/*, so there is no 
indication that this is a video.

Sizing <object>s that are embedding something like a midi file to 
200x200 is clearly undesirable, right?  That one is a little easier, 
since it has an audio/* type, of course.  I have no problem sizing those 
to 0x0, as you suggest.

It really seems like the right solution here is to fix the plugin API to 
allow plug-ins that want to communicate default sizing information to do 
so.  Anything else will either break as many cases as it fixes or 
further entrench existing market leaders; both undesirable outcomes.

> Focussing on these basic needs of embedded content (spatial, temporal 
> and audible) means that browsers can provide the basic support users 
> need without relying on plugins for those features.

There's no way to not rely on the plug-in for those features.  A browser 
HAS to rely on the flash plug-in's cooperation to provide temporal and 
audible UI, since the best it can do is make some sort of defined API 
calls on the plug-in (to pause, play, change volume levels, etc) and 
hope the plug-in listens.  Note that there is currently no standardized 
cross-plug-in API for this right now; one would have to be defined.  And 
the plug-ins would need to implement it.

> At the same time, there's no need for the HTML WG to delve into container formats and 
> codecs since regardless of those issues every video shares these three 
> properties (spatial, temporal and audible for non- silent videos). While 
> sharing a common set of codecs and containers is nice (similar to the 
> common image formats currently supported), that may happen in time 
> anyway even without WG intervention (like it did for images).

I suspect a more likely outcome is that it won't happen, with or without 
WG intervention.  At least this is the only reasonable extrapolation of 
the publicly stated positions of the various browser vendors.

>> A further problem the last time I looked at this was that assuming 
>> something other than 0x0 actually broke web pages that relied on the 
>> IE6/IE7 behavior.
> 
> It seems other browsers aren't experiencing that same breakage. Perhaps 
> the problems aren't as severe as reported. If IE8 has indeed fixed this 
> (I understood from Leif that they had),

In standards mode only?  Or in all modes?  I'll bet money on the former. 
  And is this really something that you think should differ in behavior 
between quirks and standards mode?  This isn't the sort of change we'd 
want to make only in standards mode in Gecko.

 >> Possibly, though this particular issue really could be solved by
>> adding an API for intrinsic sizing to NPAPI in Gecko; there's been a 
>> bug on that for a while now.
> 
> That sounds even better. If that can be done, I think that would be the 
> best way to fix the problem.

Fully agreed.  It'll still need buy-in from plug-ins, of course.

-Boris

Received on Friday, 13 March 2009 02:28:56 UTC