Remove <applet>

[zcorpan]

• Removed applet from document.all[name] collection.
• Removed applet from document[name] collection.
• Removed applet from window[name] collection.
• The document.applets collection now returns an empty collection.
• Removed handling for applet in <iframe sandbox>.
• Removed rendering rules for applet.
• Removed the element itself and HTMLAppletElement.
• <applet> now uses HTMLUnknownElement.

The parser is intentionally not changed.

Fixes #454.

---

Bugs:
Chromium: https://crbug.com/470301 (removed support in Sep 2015)
WebKit: https://bugs.webkit.org/show_bug.cgi?id=157926
Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1279218
Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11946645/

[annevk]

LGTM.

[domenic]

Missed the obsolete attributes section:

datasrc on a, applet, button, div, frame, iframe, img, input, label, legend, marquee, object, option, select, span, table, and textarea elements
datafld on a, applet, button, div, fieldset, frame, iframe, img, input, label, legend, marquee, object, param, select, span, and textarea elements

I am a little concerned that this removal is premature given that applet is currently implemented in 3/4 rendering engines. We have signs Edge is interested in removal, but we have heard negative signs from Gecko and no signs from WebKit.

Our precedents for removing features of this magnitude includes:

• Remove some unimplemented menu and command features #244, Remove the storage mutex #342, Fix #336: remove <input type=datetime> #357, Remove <iframe seamless> #484, Remove table sorting model #526, Remove CanvasProxy along with related concepts and complexities #790, Merge the two table cell interfaces back together #1125: no implementations
• Remove showModalDialog() #374 (showModalDialog): Firefox and desktop WebKit only
• Remove secondary browsing contexts (<link rel="sidebar">) #718 (<link rel="sidebar">): Firefox only
• Ignore beforeunload event return value #1001 (beforeunload return value): Edge only
• Remove <isindex> and <input name=isindex> #1095 (<isindex>): Firefox and WebKit only, with Firefox supportive of removal
• Remove beforescriptexecute/afterscriptexecute #1103 (beforescriptexecute/afterscriptexecute): Firefox only
• Remove MediaController and media element's mediagroup attribute #1225 (MediaController): WebKit only
• Remove <style scoped> #1226 (<style scoped>): Firefox only
• Remove form.requestAutocomplete() #1227 (requestAutocomplete): Blink only

In contrast, we have

• Remove <applet> #1399 (<applet>): Firefox, WebKit, and Edge, with Edge supportive of removal

My thoughts would be to tag this with "do not merge yet" until we get a clearer sign that this is on track for removal across the board.

[zcorpan]

Yeah, I agree.

I left datasrc and datafld alone because they are the elements on which they worked in IE. Those attributes were never part of any HTML standard. I could be convinced that those attributes should not be listed there in the first place...

[domenic]

I left datasrc and datafld alone because they are the elements on which they worked in IE.

Well, everything else in that section refers to an element that is defined in the spec, per the note at the top:

The following attributes are obsolete (though the elements are still part of the language), and must not be used by authors:

In other words, the rest of the section says "on element X, which exists, the attribute Y no longer exists." Whereas if we leave applet in there, it'll be saying "on element X, which no longer exists, the attribute Y no longer exists." Kind of redundant.

[zcorpan]

Yep, but that's also true for frameset, frame and marquee which are listed. But we can remove those too.

[domenic]

Yep, but that's also true for frameset, frame and marquee which are listed.

Those are all defined in the spec... authors aren't suppose to use them, but they're defined. After this change, applet will not be.

[qdot]

We've got a bug and an assignee (me) for removal of the applet tag in Gecko. https://bugzilla.mozilla.org/show_bug.cgi?id=1279218

[annevk]

@domenic given that Firefox is close to landing this per @qdot should we go ahead (after rebase) or wait until Firefox has shipped?

[annevk]

(Close to landing is inaccurate, my bad. It's more that we've now got @qdot looking into it.)

[zcorpan]

I think we might as well wait until Firefox has shipped.

[rniwa]

I think we should wait until at least one major browser ships this change in its stable release. It's unlikely that WebKit removes this element in near future regardless, however, due to compatibility concerns.

[zcorpan]

@rniwa Chromium removed support in Sep 2015, so has been shipping in Chrome and Opera for a while now.

[zcorpan]

I filed an issue for Edge now as it seems there wasn't one. https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11946645/

We also still need tests for this. Do Chromium or Gecko have tests or plan to write/change tests that can be upstreamed to web-platform-tests?

[annevk]

I suspect Gecko would do that, though help appreciated. Running grep applet -r * against web-platform-tests I get quite a few hits, including I think at least one browser test for it being obsolete, but also lots that assume it still works.

[qdot]

I'll handle the web platform test changes as part of the landing criteria for applet removal in Gecko.

Just curious, do we also want to deprecate code/codebase/codetype/archive/classid applet parameters that are reflected in object?

[domenic]

Great question. Interestingly all but classid are in the obsolete section of the spec; classid affects the object processing model. See "whenever one of the following conditions occur" in the object element. (Although I believe there are open issues about the object processing model not being super accurate, so I am not sure if that's true...)

Does anyone know if classid has an effect on, e.g., Flash?

It may just be easiest to leave them alone. But if implementers are up for it, it might be nice to remove this cruft too. It does seem unlikely that anyone is relying on the reflection of those Java-specific attributes into the object element given lack of Java support... @foolip, maybe you can give Chromium thoughts?

[qdot]

In gecko, classid was only used for java (See comments near http://searchfox.org/mozilla-central/source/dom/base/nsObjectLoadingContent.cpp#1625), which is why I included it as a possible candidate for deprecation. We're removing a ton of java support code along with applet, so all that code will be excised anyways.

[annevk]

@qdot according to https://lists.w3.org/Archives/Public/public-whatwg-archive/2006Aug/0134.html by @bzbarsky, back in the day Fx used to ignore the type attribute if classid was present and then go to fallback if the classid was not supported. So if we'd ignore classid altogether you'd not end up in fallback but rather end up dispatching on type. I don't know if that changed meanwhile though or if changing that code path is problematic in practice.

[zcorpan]

I prefer to leave the reflecting attributes alone. We have lots of obsolete reflecting attributes, they are cheap to support and there's non-zero risk in removing them.

[foolip]

@domenic, in Chromium, the classid attribute still appears in HTMLObjectElement, where at least part of it points back to the HTML spec:
https://chromium.googlesource.com/chromium/src/+/d5bf6c6f5651782d2fe6db6194d7e9776e2aff35/third_party/WebKit/Source/core/html/HTMLObjectElement.cpp#248

That's all what the element "represents", i.e. layout. AFAICT, the classid attribute isn't used to actually load anything, I can't find anything corresponding to this: "If the classid attribute is present, and has a value that isn't the empty string, then: if the user agent can find a plugin suitable according to the value of the classid attribute, and either plugins aren't being sandboxed or that plugin can be secured, then that plugin should be used, and the value of the data attribute, if any, should be passed to the plugin. If no suitable plugin can be found, or if the plugin reports an error, jump to the step below labeled fallback."

Not sure what to make of that.

If the reflected attributes are implemented everywhere, then keeping them even if the attributes do nothing would make sense to me.

[domenic]

Sounds like we'll leave all the reflecting attributes in. I'll file a separate issue to investigate the object processing model.

[domenic]

Actually, I guess it is fine. That step about using classid is pretty vague and it could be argued Chrome is never able to find a plugin using classid.

I think there's a larger cleanup to be done around the <object> processing model as implementations start removing support for everything-but-Flash (or even removing Flash, as some mobile implementations have done). Related: #387, where it's made clear that we're not even capturing the current heuristics very correctly. But we can leave that for later...

[rniwa]

Note that Safari does support non-Flash plugins.

[domenic]

Hmm. I think Safari started giving back empty arrays for navigator.plugins and navigator.mimeTypes, and that threw me off? Upon further reflection, that is definitely separate from what it actually supports in <object>.

[domenic]

It looks like Mozilla is implementing this; we should get ready to land, and also we should put some tests together. I can try to find time myself.

[annevk]

Rebased this PR. It does seem like WPT still needs updates since with https://hg.mozilla.org/integration/autoland/rev/e6f1f895449d @qdot simply rebased the results rather than fixed the tests...

[qdot]

@annevk Sorry, was kind of on a deadline for getting this in, and I wasn't sure what order the WPTs needed to be updated in relative to the spec. I'll file a followup in bugzilla and get that taken care of?

[qdot]

Ok, WPT updates happening at https://bugzilla.mozilla.org/show_bug.cgi?id=1386008

[annevk]

Rereading this thread I'm left unsure as to whether there's still outstanding feedback on the PR. In any case it needs another round of review.

[domenic]

LGTM with my latest commit which removes a few extra things.

[zcorpan]

LGTM.