Re: an interoperable object (fallback and context menus)

HI Boris,

On Mar 12, 2009, at 8:29 PM, Boris Zbarsky wrote:

> Robert J Burns wrote:
>> I don't have firefox 2.0 handy/installed anymore, so I'm only  
>> speaking from memory. I think with 2.0, firefox behaved more like  
>> IE8 does now (and Opera, and WebKit  too) in that it provided some  
>> default non-zero dimensions for the embedded content.
>
> Ah.  No, it did not.  Just double-checked to be sure on your test  
> pages: the flash video object gets a 0x0 size; setting some width/ 
> height styles on the node shows the flash video.

Like I said it was only from memory. I thought I recalled Firefox 2  
doing betting on these cases.

>> If plugins are limited to NSAPI , then I can understand how you  
>> cannot necessarily communicate inherent dimensions of media between  
>> plugin and browser, however there's no reason to assume zero height  
>> and width and provide no temporal controls to users.
>
> The problem is that there is no reasonable width/height to assume,  
> really.

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. Other browsers  
assume something like 200 x 200, which seems to work reasonably well.  
I think even something like a width equal to 80% or 90% of the  
containing element would be a reasonable default (and a corresponding  
height sufficient to meet most commonly used aspect ratios).  Also for  
any audio content type, it is easy to assume 0 x 0 and still know that  
temporal and audible controls need to be provided somehow (for the  
sake of both assistive and non-assistive users). This is not merely of  
academic interest. A author might use CSS to specify dimensions for  
the video, but the document should continue to render in some  
reasonable way even in the absence of the CSS (i.e., not with zero  
height and width for embedded video nor non-zero dimensions for  
audio). Likewise temporal, audible and spatial controls could always  
be provided for video content. to compensate for the information not  
provided by the author (let the user size or resize the video  
appropriately).

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

> 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), then that might  
give Gecko and Firefox the moral backing to fix it too (and present  
video with non-zero dimensions). On the other hand if this is authors  
seeking to override the users ability to control temporal and audible  
media (no pause, no mute, etc), then Firefox should not really cater  
to that need.

>> Also, perhaps we should consider addressing the plugin api problems  
>> though incubating a new plugin architecture.
>
> 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.

Take care,
Rob

Received on Friday, 13 March 2009 02:05:35 UTC