Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate <applet> #75

Closed
foolip opened this issue Sep 1, 2015 · 8 comments
Closed

Deprecate <applet> #75

foolip opened this issue Sep 1, 2015 · 8 comments
Labels
removal/deprecation Removing or deprecating a feature

Comments

@foolip
Copy link
Member

foolip commented Sep 1, 2015

There's an intent to deprecate and remove <applet> in Blink:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/E9LKKtcKbv8/BTB6dSxACgAJ

If this plan moves forward, we should deprecate it in the spec, and also remove it once it's clear whether removing it is web compatible.

@domenic
Copy link
Member

domenic commented Sep 1, 2015

<applet> also does not work in MS Edge, although they have not removed the HTMLAppletElement interface. In https://twitter.com/JustRogDigiTec/status/631973192068808705 @DigiTec expressed interest in removing it entirely.

@domenic domenic added the removal/deprecation Removing or deprecating a feature label Sep 1, 2015
@DigiTec
Copy link

DigiTec commented Sep 1, 2015

Applet doesn't function because we disallow the creation of the underlying control, but the element and type still exist. We block all but a fixed set of CLSID's. This is no different than it has been in the past. However, 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.

@domenic
Copy link
Member

domenic commented Sep 1, 2015

Thanks @DigiTec! It does indeed look like applet is treated somewhat specially in parsing. Let's try to get some clarification on blink-dev... I'll CC you there.

@zcorpan
Copy link
Member

zcorpan commented Sep 2, 2015

I remember we had some issues in Presto back in 2006 or so because applet did not have (enough) special rules in the HTML parser. I think the Web required <p><applet><p> to nest the ps rather than auto-close the applet. Possibly that is not much of an issue anymore, or it becomes moot if applet shows its fallback anyway, but it seems to me it is somewhat risky and I see little benefit in changing the HTML parser.

@foolip
Copy link
Member Author

foolip commented Sep 2, 2015

Overall usage of <applet> is very low, but it should be possible to measure how often the parser bits actually make a difference if one wanted to remove <applet> fully. But leaving the parser as-is also seems fine to me.

@Ms2ger
Copy link
Member

Ms2ger commented Sep 2, 2015

Given the existing interop between browsers and other HTML parsing libraries, I'd prefer not changing the parser in general.

@foolip
Copy link
Member Author

foolip commented Sep 2, 2015

OK, let's do it! Not change the parser, that is.

@foolip
Copy link
Member Author

foolip commented Sep 2, 2015

It's clear from blink-dev that the removal will be attempted at Blink, so I'll make the change to deprecate in the spec now. We can figure out the details along the way, and discuss wherever convenient, including this issue even if closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
removal/deprecation Removing or deprecating a feature
Development

No branches or pull requests

5 participants