Where is the Web Browser Plug-in Task Force?

Posted on by

Let’s face it, using plug-ins in your website is a pain in the ass. Most of the documentation provided by plug-in makers is either grossly outdated or non-existent, and when you do find useful information, one plug-in maker might have you use one method, and another has a completely different set of rules.

HTML has had proper support for plug-ins for a long time: the object tag, which is flexible enough to handle pretty much anything you can throw at it. But because of the [wrong] way many browsers interpret this information, many plug-in vendors still require (or at least suggest) the use of the embed tag either along with or instead of the object tag. Why is this? It’s 2006! Lets put some pressure on these companies to make things easier for us as developers. Why can’t I layer HTML over my Flash content or my Quicktime content? Why does Internet Explorer make me use this crazy classid attribute when specifying a mime type should suffice?

It’s time to clean up the world of browser plug-ins. It’s not enough to just sit back and say plug-ins suck, or that the very nature of them doesn’t fit into the ‘Web Standards philosophy.’ Whether you like it or not, they are here to stay. Standardizing them won’t be easy (If things like this were easy, the Web Standards Project wouldn’t exist), and it will probably take years to do, but it’s something that really needs to be done.

22 thoughts on “Where is the Web Browser Plug-in Task Force?”

  1. Actually, the W3C’s version of the OBJECT tag was introduced only after “many years of proper plugin support”, and the difficulty has been in the world’s browsers and content shifting from one tag to the other.

    “Why can’t I layer HTML over my Flash content or my Quicktime content?” You can, with the WMODE compositing mode offered by many browsers. If, however, this realworld tag is defined-away later, as happened with EMBED, we’d be back in a similar difficult situation. (I believe the QT plugin also supports this, but would defer to their docs.)

    “Why does Internet Explorer make me use this crazy classid attribute when specifying a mime type should suffice?” Good point. Microsoft introduced OBJECT, with numeric identifier to specify the renderer, a bit after Netscape introduced EMBED tag with media-type identifiers. A few years later the W3C blessed the OBJECT tag, but with a media identifier (mimetype) instead of a renderer identifier (clsid). I haven’t seen the browsermakers document how thoroughly they move to this new OBJECT… most seem to have simple visibility now, but there are problems with screenreaders, streaming, other issues in some browsers when a W3C-style OBJECT is used. I don’t know of any opensource wikis documenting these browser/spec differences.

    I agree with you that extensibility is a normal trait of WWW document browsers.

    For your first sentence, are you having a particularly tricky problem in extending browsers right now, or is it more like better integration and lesser variability that you’re seeking in general?

  2. You can, with the WMODE compositing mode offered by many browsers.

    But it’s really buggy, and has many small caveats in order to make it work properly, and even then it’s still fairly buggy, with Flash content popping up for a peek now and again.

    most seem to have simple visibility now, but there are problems with screen readers, streaming, other issues in some browsers when a W3C-style OBJECT is used.

    These are exactly the issues I’m trying to highlight – What we need is someone putting pressure on the browser makers to unify how they invoke plugins.

    I’m not having any specific issues, really. This train of thought came from building the FlashObject script, and needing to detect different browsers and send them different sets of HTML to get them to display things properly. Another issue is when you use the DOM to create these elements – because you have to create special HTML, often with proprietary attributes and tags (like embed), it becomes a major hassle to keep track of all this stuff. Opera won’t even let you create elements or add attributes that aren’t in the DOM.

    So it’s really more of a general distaste for the state of browser plugin-handling and rendering than a specific issue.

  3. I guess my first question to you would be what’s some low hanging fruit that trips you up either on the browser side or the plugin vendor side with recently released apps? Outside of your DOM issues which arise becuase you’re using legacy code what other things do you hit, or would hit if you didn’t try that route?

    Though I don’t spend all that much of my time dealing with the finer points of plugin integration and communication I do see it as quite a messy and fragmented space and I’m not sure which approach might get the most done. Something not mentioned here but you’ve hit on before — good authoring practices — could do a lot of good if a more visbile group tackled it, but I’m not sure that would really do you much good.

  4. Here’s some things to start with:

    For the browser makers:
    – Fix how your browser handles the object tag.

    For the plug-in makers:
    – Make sure your plug-in works with the object tag. I know this is largely dependant on how the browser handles the object tag, but we have to start somewhere.

    For the public:
    – Educate people on proper plug-in usage, try to wean them off the embed tag – but to do this, first we need solid object tag support in the browsers.

    This is mainly focusing on better object tag support in various web browsers. Once we have solid support, there will be no reason to use the old methods.

    Maybe it could be called an “Object tag Task Force”? ;)

    I could see it leading other things related to browser / plug-in harmony, like facilitating future creation of standards like the NPRuntime standard.

  5. It is the job of the company introcducing a technology to provide users effective guidelines to be enabled to use the product.Any discrepancies in the use of the technology means that the company needs to introduce effective literature and know-how to explain the product adequately.

  6. This is true, but there are standards in place for the implementation of that technology, so the browser makers also are responsible for supporting the standard.

  11. I guess the browser developers have some responsibility, but as most browsers, (if not all) are free,… it’s a difficult requirement to implement, except for voting with your feet, of course.

  12. Hi,

    I need help in creating a Javascript code for embedding the VLC plugin in the web browser. I am a novice at this. Please help.

    Regards,
    Neeraj

Comments are closed.