W3C home > Mailing lists > Public > public-html@w3.org > March 2009

Re: an interoperable object (fallback and context menus)

From: Robert J Burns <rob@robburns.com>
Date: Thu, 12 Mar 2009 23:28:56 -0500
Cc: HTMLWG <public-html@w3.org>
Message-Id: <5344052C-E4EE-4046-B975-D992DB06E6A9@robburns.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
HI Boris,

On Mar 12, 2009, at 9:28 PM, Boris Zbarsky wrote:

> 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?

Well presumably you had to perform some algorithm on it to determine  
it is a type you don't know how to handle. 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).

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

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  

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

Certain objects could receive the current size of 0 that you're using  
for all embedded objects, but others could be excluded from that and  
receive non-zero dimensions.

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

I agree. Do you happen to have a bug id for that. I'd be interested in  
tracking that. I think it would be helpful to improve the plugin API  
much more than placing additional burdens on authors and users.

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

I understand. That is why I earlier suggested that this WG might  
itself or encourage another effort to improve plugin APIs. In this way  
authoring can remain and even become simpler while providing even a  
richer experience for users.

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

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?). 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). This makes  
sense. If an author really wants to hide an embedded object behind  
zero dimensions, then they should be expected to do that explicitly  
(if even then, there's reason that users should have some access even  
then to for example, stop incessant background audio files). As I said  
earlier perhaps even 90% of the width of the containing element with  
the height in a range corresponding to typical aspect ratios might be  
even a better default (for audio/* and other types this could be  
reduced to just enough for the usual plugin controls; again allowing  
the spatial resizing and aspect ratio changes by the user).

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

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?

Take care,
Received on Friday, 13 March 2009 04:29:36 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:45 UTC