Re: an interoperable object (fallback and context menus)

Robert J Burns wrote:
>> Well, hold on.  How do I know it's video?
> 
> Well presumably you had to perform some algorithm on it to determine it 
> is a type you don't know how to handle.

Sure.  I compared it against a list of types I _do_ know how to handle, 
and it didn't match any of those.  That tells me all sorts of things 
about what it's not, but nothing about what it is.

> In doing so you might also be able to eliminate some types. For example, if you determine its a mime 
> type that starts audio/, then you might include zero dimensions 
> (however, the competing browsers provide dimensions even for audio so 
> it's apparently not a major complaint from users).

Maybe; it's hard to say.  <object> usage on the web is low enough, 
especially without a classid attribute, that maybe there are just no 
audio objects out there...

> I think it would be perfectly safe to include non-zero dimensions (even 
> if errantly for audio) and also provide UI to resize and collapse (to 
> zero dimensions) embedded objects without startling user sensibilities.

It's not "user sensibilities" I'm worried about.  Or rather not that the 
user will OMG see the <object> but rather that something taking up space 
when the author expects it not to can seriously break some of the more 
complex layouts out there, to the point where nothing will be remotely 
close to where it should be.  The user might not even be able to locate 
the object to collapse it in these sorts of situations.

Again, maybe I'm worrying about an authoring case that just doesn't 
exist nowadays.

>> It really seems like the right solution here is to fix the plugin API 
> 
> I agree. Do you happen to have a bug id for that.

https://bugzilla.mozilla.org/show_bug.cgi?id=70976

>> 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.
> 
> I never raised the different modes. I think this should work 
> consistently in either mode (do we really want to add to the differences 
> between modes?).

Gecko doesn't, and Opera hasn't, but I bet IE did.  I don't have an IE8 
beta to test here, though, and I'd love to hear that I'm wrong.

> Firefox is not consistent with other browsers now. The 
> others all provide some small non-zero dimensions to embedded objects by 
> default (something like 200 x 200).

Safari seems to use the default 300x200 size for CSS replaced elements 
without intrinsic dimensions instead, but ok.

Do you know whether there's a bug filed on this?

> Again, you earlier mentioned a known issue. Is there an bug id in 
> mozilla's tracker on this? Or somewhere else? Does Mozilla maintain the 
> NSAPI specification? Or are you talking about specifically 
> Gecko-specific enhancements to the plugin API?

To my knowledge, there is no NPAPI specification past "what works in 
Netscape 4."  Opera, Gecko, and Safari all have implementations of NPAPI 
that agree on the basics; I would not be at all suprised if they differ 
in some of the details.  In this case I would be talking about a 
Gecko-specific addition to Gecko's NPAPI implementation, though there 
would be nothing stopping Opera and Safari from implementing it as well. 
  Last I heard, plugin-futures@mozilla.org a mailing list where 
discussion about NPAPI changes happens and where representatives of the 
developers of all three three of the above browsers, as well as various 
plug-in vendors, participate.

IE doesn't use NPAPI, so all of this is not relevant to it; I don't know 
whether the ActiveX plug-in API allows a plug-in to specify intrinsic 
sizing already, or expose a standard API for pause/stop/play/etc.

-Boris

Received on Friday, 13 March 2009 16:41:08 UTC