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

[whatwg] WhatWG and <embed>

From: Shadow2531 <shadow2531@gmail.com>
Date: Sat, 19 Aug 2006 13:08:24 -0400
Message-ID: <6b9c91b20608191008oc274b9dq39cc6f9aa025d8c1@mail.gmail.com>
On 8/18/06, Christian Biesinger <cbiesinger at web.de> wrote:
> Hi,
>
> I got a question about <embed>. Firstly, does WhatWG intend to document
> that element and how it works?
>
> Secondly, if so:
> Consider an <embed src="testmovie.wmv">. Consider that said system has a
> plugin installed that can show movies in that format (that is,
> video/x-ms-wmv). The plugin can also handle "*.wmv" movies.
>
> Now, imagine that the server sends a type of text/plain for this file.
>
> What should happen?

If text/plain is sent, I expect it to fail unless you have a
text/plain plug-in installed. Even then though, the video wouldn't
play because it'd be a text/plain plug-in, not a video plug-in..
However, if no type at all is sent ( like if you're loading a local
page that embeds a local wmv file), then I'd say use the extension as
a backup.

I think the type attribute should be required though and things should
fail if the type sent by the server doesn't match the type attribute.
An exception would be the generic types like application/x-mplayer2 ,
which are allowed to embed more than one type or any type ( because
they support more than one type. )

Also note that some plug-ins like the real plug-in are very picky.
Unless you have a modified one, not only does the file have to be sent
as audio/x-pn-realaudio-plugin, but it has to have an .rpm extension.
If you have rpmfile.php for example that sends
audio/x-pn-realaudio-plugin, you'll be lucky if it works because the
extension is .php instead of .rpm. It can be that picky.

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.

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 most likely a video. In
situations like these, it might be best to make it work.

Now,  on the other hand :), having browsers go out of their way to
make things work makes it all that more O.K. to send files with the
wrong type, which we don't really want.

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

I'm kind of undecided. I'd like to see a lot of discussion on all this.

I'd like to forget about the embed element and just stick with the
object element though. ( 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.)

-- 
burnout426
Received on Saturday, 19 August 2006 10:08:24 UTC

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