- From: Robert J Burns <rob@robburns.com>
- Date: Thu, 12 Mar 2009 23:28:56 -0500
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: HTMLWG <public-html@w3.org>
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 sensibilities. > 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, Rob
Received on Friday, 13 March 2009 04:29:36 UTC