[Bug 6102] Please do not break applet element in HTML 5

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6102





--- Comment #5 from Michael A. Puls II <shadow2531@gmail.com>  2008-09-22 11:52:31 ---
In Firefox for example, Java is just another NPAPI (I assume npruntime in
latest dev/beta version for Firefox) plug-in (with a Java-specific toggle for
it in the UI). That being said, there's nothing special about it to Firefox,
generally (Mozilla devs can correct/clarify). It's just another plug-in that
should be loaded with <object> or <embed> (using mime types the detected
plug-ins report they support. Whether that's application/x-java-applet or not
depends on the plug-in).

Even though the Sun Java plug-in doesn't currently support asking for the @src
or @data file the browser's currently downloading, this will at least work
right now in Firefox, Safari and Opera:

<object type="application/x-java-applet">
    <param name="code" value="MyJavaClass">
    <param name="codebase" value="http://example.com/dir_files_are_in/">
    <param name="archive" value="test.jar">
    <param name="mayscript" value="true">
    Java is off or not installed
</object>

This will probably work too:

<embed type="application/x-java-applet" code="MyJavaClass"
codebase="http://example.com/dir_files_are_in/" archive="test.jar"
mayscript="true">

However, there are other problems. Opera doesn't use the Java plug-ins. It
supports loading Java natively (interfaces with the JRE directly) and is
triggered by application/java* and application/x-java*. Applets are not cached
in %appdate%\sun <http://my.opera.com/community/forums/topic.dml?id=91659> and
applets are not guaranteed to have the same support that you might get from the
Java plug-ins. This also means that version detection with the versioned mime
types doesn't work (This looks like it's solved in the new Java plug-in as a
param, but doesn't seem like that will work with Opera). Also, since <noembed>
is tied to the global plug-ins on/off toggle in Opera, you can't have Java on,
plug-ins off, use <embed> to load Java and expect <noembed> to work right. 

(Not sure how Safari interfaces with Java)

Firefox and Opera can also trigger Java with <object
classid="java:MyJavaClass"> (per HTML 4.01 W3C example), but that might be
quirky in Safari.

IE uses <object class="clsid:clsid:8AD9C840-044E-11D1-B3E9-00805F499D93">
(Which with IE conditional comments can be used to provide an IE-compatible
<object> for IE)

There's also the case where <object codebase="" is different in IE and other
browsers.

Also, whether the window.java JS object is available and how much of it can be
accessed is not compatible across browsers.

What this basically means is that embedding Java and using it across browsers
the same is a mess (unless you keep it really simple).

Now, using <applet> can hide a lot of the mime type/classid noise (as long as
browsers make <applet> fall back *exactly* like <object> does when it's trying
to load an applet), but there are still a lot of cross-browser issues that need
to be fixed outside of HTML5.

With that said, <applet> allows authors to say "I don't care how you interface
with Java, just load it dammit!". However, this is a poor excuse for Sun not
supporting OBJECT (and @data) properly and a poor execuse for browsers not
interfacing with Java all the same and a poor excuse for IE (In 8 standards
mode at least) not supporting <object> with @type and @data. 

<applet> just hides all the problems. It doesn't solve enough problems to make
it a valid element, imo.

In conclusion:

I think that <applet> should not be valid HTML5, but HTML5 should specify how
<applet> is handled (including fallback). However, only the standard attributes
for <applet> need to be specified in the handling. All the
implementation-specific <param>s (including any new ones) shouldn't be
specified in HTML5, as they're ... implementation-specfic and just <param>s.
(Unless we want to merge *lots* of Java spec stuff into HTML5.)

Ideally, if the Sun Java plug-in supported <object> and <embed> (and all
browsers used the plug-in) applets would be automatically supported in browsers
(that properly support <object> and <embed>) like this:

<object type="application/x-java-applet" data="MyJavaClass.class">
    MyJavaClass.class wasn't found or Java is not installed or is off.
</object>

<embed type="application/x-java-applet" src="MyJavaClass.class">

(That would be possible too and the plug-in could support the old code param
too for backwards-compat.)


One last thing though. There should be such a thing as an HTML5-compliant
plug-in. It must be npruntime and support requesting the main file the
browser's downloading from @data or @src. Then, perhaps the Java plug-in could
be HTML5-compatible.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 22 September 2008 11:53:06 UTC