This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I am the technical lead of the Java Plug-In at Sun Microsystems. This software provides Java applet support in the web browser. I apologize for filing this bug this late, but it was just pointed out that the current HTML 5 specification obsoletes the applet element. It is true that it has been deprecated for some time. It isn't clear to me from reading the section in the specification whether this step will cause browser vendors to no longer support the applet tag. I am writing to ask that, if this is the case, that this element be left as deprecated, incorporating its previous full specification. We at Sun are continuing to progress applet technology; please see https://jdk6.dev.java.net/plugin2/ . While we certainly appreciate the desire to treat all extension technologies equally, there is a large amount of existing Java content on the web which uses the applet tag, and the applet tag continues to be a convenient, cross-browser shorthand. Please continue to include the applet element as part of the HTML 5 specification, even in deprecated form.
Browsers won't stop supporting it so long as there is content that uses it (this is true regardless of what the spec says). HTML5 will define how to implement it. Does that address your concerns?
Thanks, that does largely address my concern. We would like to make sure the new spec contains the information about the attributes and semantics of the element from the previous spec, even though the element is marked obsolete. In parallel we are going to work on making the object tag work in cross-browser fashion as described in the HTML 5 specification, in particular adding support for the application/x-java-applet MIME type in Internet Explorer; see http://bugs.sun.com/view_bug.do?bug_id=6750726 (not visible yet, but should be visible in a day or so).
Cool. HTML4 was pretty vague about how things should work (e.g. how should the Java plugin be instantiated? What are cross-domain limits? What's the JS API exposed? What happens if the Java class instantiated is missing the start() method? And so forth.). I'm not really in a position to reverse engineer the exact requirements, so if you have any detailed documentation on what the spec should say exactly, that would be great.
So the spec is expected to recount in detail how <applet> works in browser implementations but then make it non-conforming to author (i.e. say that validators must flag <applet> as an error). There are various things to consider: 1) We might want to try to push people to use technologies that are contained in browsers (JS plus browser-provided APIs) instead of Java, Flash or Silverlight (in order to promote code that works anywhere that a full browser engine runs including devices like Wii, N800 or the iPhone). 2) One might argue that it's politically wrong for Java to have its own element when Flash and Silverlight don't. 3) According to Sun's documentation, <applet> works better cross-browser than <object> for instantiating Java. 4) Anecdotally, current practice seems to favor <applet>. (I haven't actually analyzed Web pages systematically to verify this.) 5) <video> was introduced because making <object> have many context-dependent JS APIs was considered bad. Wouldn't the same argument apply to having a specialized element for Java applets instead of trying to put everything into <object>? So what's the real motivation for making <applet> non-conforming? If it is to make people avoid technology that isn't built-in to the interoperable platform (point 1), does it work towards that goal? That is, will obsoleting <applet> for the purpose of conformance make people use applets less? Or will some people switch to <object> and others continue to use <applet>? Does switching to <object> benefit anyone considering points 3, 4 and 5? Should point 2 matter? Perhaps in retrospect, having a special element for Java isn't politically right, but can't we just grandfather it in for historical reasons and not bother people about switching to <object>? Also, now that HTML5 makes <embed> *conforming*, the spec effectively has an element that is there primarily to enable Flash. (Take a look at the installed plug-ins of a normal user. Then take away Java which has <applet>. Then take away plug-ins that will be obsoleted by <video>. What's left?) (Note: I don't have any interest in *promoting* Java applets. In fact, I've never seen an applet that wouldn't have been more appropriate either as a Java Web Start app, as a JavaScript/<canvas> app or as a native browser feature. I'm looking at this from the point of view of a validator developer, and bothering people about switching from <applet> to <object> doesn't seem productive.)
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.
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.