[whatwg] WhatWG and <embed>

[Shadow2531]

On 8/21/06, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> 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?

No. The file will still be played.

I expect it ( not necessarily saying I want it ) to fail because the
Windows Media plug-in in this case does not report that it supports
playing text/plain media. It says it supports the .wmv extension, but
what if I have a text/plain plug-in? Will it load in the plug-in
associated with text/plain or in the windows media plug-in or other?

I'd like to see the steps spelled out *exactly* because HTML 4.01 does
not do that.

Also, what about this <embed src="file.asx"> (where the asx file is
served as text/plain).  What if I really want it embedded as a text
file and don't want it embedded with the wmp plug-in?

> > I think the type attribute should be required though
>
> Again, does that match current UA behavior?

No. Things usually work without a type attribute.

I think it should be encouraged though. It does have it's uses.

It's a great hint if the browser can't figure out what to do with the
mime type sent, if any, and the extension doesn't help.

Also, whether it currently works correclty this way or not,
type="application/x-mplayer2" for example means to load the src with
the windows media plug-in regardless of the the extension or type and
leave it up to the plug-in to decide whether the file is supported.

For example, <embed type="application/x-mplayer2" src="file.gif">
should load with the windows media plug-in and will in Firefox.
However, in Opera, it might load as just a gif file unless the gif
file is sent as application/x-mplayer2.

Also, <embed type="sometype"> without a src could be used to invoke a
plug-in for scripting so that scripting could set a source.

Maybe having a nosrc="true" attribute would please me for this.

Also, ( this is more with the object element ), if I specify a type=""
and the server sends the file with a type that doesn't match, I might
want the alternate content to display.

Those are just some reaons for the type attribute.  Of course you
might say then, "If that's so, do you think the type attribute for A
should be required too?". I'd  say, "no".

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

If the type attribute is required and things failed if the server
content-type doesn't match, then maybe we wouldn't have so many people
embedding files sent with the wrong type.

Maybe having a strict="true" for that would please me.

We also don't want to give the plug-in something that it doesn't say
it supports. Unless we want to give it everything and let it sort
things out.

We need some type of standard for plug-in development too as most
plug-ins don't use a data param and browsers have to map it to a src
param.

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

*That* is exactly what I would like spelled out. Something specific
that all browsers can follow because I think things are quite chaotic.

I know we can't break pages, but I believe strict handling of things
would be better in the long run. That's not for me to decide alone
though of course.

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

.htaccess will take care of that and we should encourage people to
change things to be sent with the correct type any time possible.

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

Better for the web. Take XML for example. If your markup isn't right,
you'll know it when the browser parses it. You are then basically
forced to have it right or it won't work.  Making things strict with
embedding would straighten a lot of these nasty web sites out. Again,
I believe it'd be better in the long run, but I'm torn between doing
that and making everything work no matter how incorrect things are.

> > I'd like to forget about the embed element
>
> Not acceptable -- <embed> is the one existing sanely cross-browser way of doing
> plugins.

Yep, but I don't like it. :)

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

Thanks.

If classid and data are both present, Firefox ignores the data and
gives the classid a shot. If there's no activex plug-in installed that
handles the clsid, Firefox fails and goes to alternate content.

It looks like you're saying that people that target the activeX method
don't want to fall back on the NPAPI method.  But, what if an author
wants to?  You'd probably say to use alternate content and another
object tag or embed tag.

However, I think it'd be neat to fall back (or give the option through
an attribute or something to fall back ) on the data off the current
object element.

Opera doesn't do classid stuff (except for java) so it can ignore the
classid and use data.  This allows Object tag markup that works in
both IE and Opera, where it will fail in Firefox if there's no ActiveX
plug-in.  If Opera ever does make use of classid for something, Opera
might hit the same issue as Firefox and I hope there's a neat way to
use data as a fallback instead of doing the Firefox way.

I'll see about explaining more the  nosrc and strict attributes I'm suggesting.

-- 
burnout426