Intent to Deprecate and Remove: Support for <applet>

[Daniel Cheng]

Contact emails dch...@chromium.org

Summary The <applet> tag is only used to instantiate the Java plugin. Running the Java plugin requires NPAPI support, but NPAPI support in Blink has already removed. We should just remove any special handling for <applet> and let it be handled like any other unspecified tag: in the HTML spec, it is listed under obsolete features, with the header text "Elements in the following list are entirely obsolete, and must not be used by authors". Motivation

This actually improves the state of <applet> in Blink. Right now, users just see a placeholder that says "This plugin is not supported". However, we should really be displaying the fallback content, since we have no intent to support NPAPI/Java at all.

Compatibility Risk Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals Describe the degree of compatibility risk you believe this change poses

Minimal, since Blink has no NPAPI support.

Usage information from UseCounter

This feature is not instrumented.

OWP launch tracking bug https://crbug.com/470301 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/6246781461463040 Requesting approval to ship?

Yes.

[Jochen Eisinger]

lgtm

[Rick Byers]

LGTM2

[Chris Harrelson]

LGTM3!

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

Obsolete features must not be used by authors, but must be implemented by vendors, as far as I know
Removing the interface and all of its properties (what about document.applets?) may be problematic. Do you have any usage data?

☆PhistucK

[Daniel Cheng]

I'm currently experimenting with a patch which removes it altogether just to see what the impact would be. Among other things:

- document.applets and window.applets would only return <OBJECT> tags that are applets, and not <APPLET> tags.

- The HTMLAppletElement constructor would be removed.

- Named access on the window object would no longer lookup <APPLET> tags by name.

So there are definitely some web visible effects....

The good thing is I was wrong about the use counter: there is a use counter [1] for <APPLET> and it shows that usage is already well under <0.01% and dropping. So I think that removing this will have minimal effect on the web ecosystem, even with the changes above.

Daniel

[1] https://www.chromestatus.com/metrics/feature/timeline/popularity/280

[PhistucK]

A use counter for <applet> is one thing, but what about the interface itself and its members? Perhaps it is used for a browser-through-a-faulty-feature detection (for example, detection of Internet Explorer 8 and other relatively modern browsers with interfaces), who knows.

☆PhistucK

[Philip Jägenstedt]

LGTM4, but can you also file a spec bug to have it removed from HTML? https://whatwg.org/newbug

[Philip Rogers]

Our standard release process should be sufficient to catch browser sniffing bugs caused by the removal of these apis. I think it's unlikely this will break anything.

[Elliott Sprehn]

On Thu, Aug 13, 2015 at 10:57 AM, Philip Rogers <p...@chromium.org> wrote:

Our standard release process should be sufficient to catch browser sniffing bugs caused by the removal of these apis. I think it's unlikely this will break anything.

This will break the layout of the pages using the applet element, removing all support means we won't support the presentation attributes which likely causes lots of pages with fallback content to look busted. ex. width/height attributes would stop working.

I don't think we should remove *all* support like this.

- E

[Daniel Cheng]

My understanding is that presentation attributes do not apply to fallback content. I wasn't able to confirm this in Firefox (I could only get it to display various plugin placeholders), but Safari seems to follow this.

Daniel

[Alex Russell]

I think we should remove support, but only when we have the usecounter data back to show it isn't going to break a lot of things.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Daniel Cheng]

I mentioned this earlier, but it might have been missed in the earlier replies: we do have a use counter for HTMLAppletElement, and it is well under 0.01%.

Daniel

[Elliott Sprehn]

On Fri, Aug 21, 2015 at 5:36 PM, Daniel Cheng <dch...@chromium.org> wrote:

My understanding is that presentation attributes do not apply to fallback content. I wasn't able to confirm this in Firefox (I could only get it to display various plugin placeholders), but Safari seems to follow this.

That's not what I see in Safari.

<applet code="" width="150" height="150" style="border: 1px solid red; display: block;">

    Hello World.

</applet>

Renders a 150px square, they definitely still respect the presentation attributes.

- E 

[Will Harris]

Hi - given the usage is so small (0.01%) and right now Chromium does not even display the fallback content at all, is this really something we should be adding more complexity to fix?

Will

[Daniel Cheng]

Hmm: I didn't consider the interaction between the presentation attributes and display: block / display: inline-block.

That being said, given that:

- <applet> usage is super low

- display: block, display: inline-block, etc. have to be set

I think removing complete support will have a very very very small compatibility effect.

Daniel

[Chris Harrelson]

One option to avoid this compatibility risk is to implement the presentation attributes on HTMLAppletElement (but still remove all other functionality). I think this should be straightforward by making HTMLAppletElement inherit from HTMLElement rather than HTMLPluginElement, and implement these methods on it:

    bool isPresentationAttribute(const QualifiedName&) const override;

    void collectStyleForPresentationAttribute(const QualifiedName&, const AtomicString&, MutableStylePropertySet*) override;

with an implementation copied from HTMLPluginElement. Then you could also keep the applet-specific user agent CSS also in html.css.

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

Without more specific use counters we can't really say what the compat risk here is, but I would support an attempt to remove <applet> entirely, and revert to keeping some of it only if it proves necessary. To do the removal in two steps (the other path to complete removal) doesn't sound great, so if direct removal seems too risky, then more use counters would be a good alternative.

[Philip Jägenstedt]

I've filed a spec issue: https://github.com/whatwg/html/issues/75

[Chris Harrelson]

The API owners met today to discuss this Intent.

The consensus was that we should proceed with full removal of <applet>, without preserving special behavior of fallback

content in the presence of presentation attributes. We concluded that the risk stemming from that is seems small enough,

and is therefore outweighed by the complication of keeping around code and having to have a two-phase deprecation in

the future.

We also identified that the risk for enterprise deployments is higher, and so we will proactively reach out to enterprise

customers to make them aware of this change.

Thanks,

Chris

[Domenic Denicola]

In the spec discussion [1], Justin from the Edge team (CC'ed) mentioned:

> we are also willing to remove the element entirely. My main concerns are with parsing semantics. We want to ensure that when we remove the element itself, that the parser still does the correct thing. We had issues with BGSOUND when we removed it that come to mind.

Daniel, what were your plans with regard to parsing behavior? There are a number of ways in which it is treated specially currently; Ctrl+F for "applet" in [2]. Was the intent to keep the parsing rules, but produce HTMLUnknownElement? Or was it to entirely remove applet, so that it parses the same as <asdfdsf>?

[1]: https://github.com/whatwg/html/issues/75
[2]: https://html.spec.whatwg.org/multipage/syntax.html#parsing

[Daniel Cheng]

Sorry I missed this message. The removal is a complete removal, without keeping any special parsing behavior around.

Daniel

[Anne van Kesteren]

On Mon, Sep 28, 2015 at 11:55 PM, Daniel Cheng <dch...@chromium.org> wrote:
> Sorry I missed this message. The removal is a complete removal, without
> keeping any special parsing behavior around.

What's the rationale for that? Parsing legacy documents differently
doesn't seem great.


--
https://annevankesteren.nl/

[Daniel Cheng]

Well, I don't think there's any rationale other than I missed the message from Domenic. Given that there already seems to be precedent for keeping special parsing rules around, I'll just add back the special parsing rules for <applet> but have it parse into an HTMLUnknownElement.

Daniel