[whatwg] The embed element

[Shadow2531]

On 4/26/06, Ian Hickson <ian at hixie.ch> wrote:
> I don't envisage keeping <applet> around unless someone can specify it in
> enough detail and give a convincing case for its inclusion.

At the least, Opera and Firefox can not expose java methods in an
applet to javascript when you use the object element. <applet
mayscript="true"> must be used.

For example:
<http://shadow2531.com/opera/testcases/plugins/java/002.html>

That loads a Java applet and shows Javascript<-->Java communication.
That's not possible in Opera and Firefox if you use the object element
to load the applet.
(It even works in IE, so you can test it there too.)

So, currently, there's a need for <applet> and the mayscript attribute.

Another example:
<http://my.opera.com/burnout426/homes/files/wmp_netscape_scripting.zip>

That shows how to make Windows Media Plug-in methods and its callback
events available to javascript ( In Opera 9 win32 builds at least. ) .
It loads an applet for npds.zip, which exposes the plug-in methods.
Again, it doesn't work with <object> because <object> doesn't expose
scripting of applets. <applet mayscript="true" must be used here too.

<object> is supposed to be used in place of <applet>, but that can't
happen in all situations currently.

Even if <object> supported exposing applet methods to javascript, how
would you turn it on.? HTML4 doesn't define 'mayscript' for <applet>
and nothing defines 'mayscript' for <object>.  Should it be some
HTMLObjectElement.mayscript method?

As for <embed>, if it behaved just like <object> (minus the param
elements), that would be great. Currently, <embed>  is an empty
element though.

The problem with <embed> is that it doesn't support fallback content.
There's <noembed>, but that's only for when the <embed> element itself
is not supported (because you have plugins turned off in your browser
or something.).  Plus, <noembed> isn't really tied to any certain
<embed>.

Another thing to make clear is, the default width and height.  Opera
for example currently gives a default height and width that looks to
be about the same size as a default java applet size. In Firefox, if
you don't set a width and height, they are 0.

Also, <embed> in Opera doesn't collapse in situations like this:
<embed src="http://filenotfound" width="1000" height="1000">

You just get a big plug-in content area on the page.

There needs to be a defined behavior for what should happen here.

The good thing about <embed> is that it usually works more often.
This is basically because most plug-ins that require a src don't
recognize the data param of <object> and browsers have to jump through
hoops to invent a src param when using <object> to make those nasty
plug-ins work.  Plug-in developers need to shape up.

To add, <object>'s codebase attribute is most of the time misused.
It's supposed to be a basehref for the data and classid attributes (or
in the case of java, the directory where the class files are at).
However, IE-goers use the codebase to specify URIs to cab files.  This
means that 'codebase' has to be ignored if it has junk in it like a
uri to a .cab file.

As for Firefox not ignoring the classid when it sees
classid="clsid:", that's a problem. Firefox should ignore it and use
the data attribute. Of course Firefox *can* (with a plug-in) support
activeX methods for the Windows Media Plug-in. In these situations,
Firefox should honor the classid, but only for ones that it supports.
This needs to be spelled out clearly so that the Firefox devs are
officially allowed to favor the data attribute.

On a side note, I always wanted to do this:
<object type="application/java" data="file.class" codebase="directory">
If the jre throws an error you see this and not an applet displaying
that there was an error.
</object>

Fallback mechanisms don't currently work for java.  Alternate content
for java is like the <noembed> tag where it only works if java isn't
supported (because you have it off or not installed.). Plus java can't
really make use of the data attribute. Browsers currently don't
support it that way anyway, but it'd be nice.  Something to think
about at the least.

As for plug-in developers, I'd like to see, "Our plug-in is HTML4 and
or HTML5 compliant. Our plug-in can be loaded via the embed element or
the object element without browsers having to map parameters around.".
If we could get the major plug-in developers to conform, that'd be
great.

There are plenty of things that need to be cleared up.

-- 
burnout426