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
Comments
|
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. |
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. |
I remember we had some issues in Presto back in 2006 or so because |
Overall usage of |
Given the existing interop between browsers and other HTML parsing libraries, I'd prefer not changing the parser in general. |
OK, let's do it! Not change the parser, that is. |
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. |
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.
The text was updated successfully, but these errors were encountered: