W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2006

[whatwg] WhatWG and <embed>

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Sun, 20 Aug 2006 23:13:32 -0500
Message-ID: <44E932EC.1020507@mit.edu>
Note: I'm not on the whatwg mailing list, so please cc me on replies.

Shadow2531 wrote:
> If text/plain is sent, I expect it to fail unless you have a
> text/plain plug-in installed.

Does that match current UA behavior?

> I think the type attribute should be required though

Again, does that match current UA behavior?

> and things should fail if the type sent by the server doesn't match the type attribute.

Why?

> Basically, the browser should follow the rules of the plug-in and only
> invoke the plug-in for types and extension the plug-in says it
> supports.

Sure, but the question is how one should decide what type to use for the data in 
question.

> Your text/plain example is a good example. If you embed a .wmv file,
> we know no matter what it's sent as

It's sent as text/plain.  Always.  Thank you, Apache!

> Making <embed src="testmovie.wmv"> ( sent as text/plain ) fail may
> seem evil, but it might be for the better.

Better what?

> I'd like to forget about the embed element

Not acceptable -- <embed> is the one existing sanely cross-browser way of doing 
plugins.

> ( And explicitly say that it's O.K. for a UA to
> ignore a classid it doesn't support and use the data attribute
> instead, for Mozilla's benefit.)

Also not acceptable (speaking as a Gecko developer) -- we don't want to deal 
with the issue that will arise when content meant for ActiveX plugins gets sent 
to NPAPI ones, which have different bugs, etc.  The current setup (where the 
site can choose which one to target and can easily target both), is quite nice 
that way.

-Boris
Received on Sunday, 20 August 2006 21:13:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:28 UTC