Remove <applet> (except for parsing rules) #454
Comments
|
@Ms2ger, what is the status of Gecko/Servo? |
|
Servo doesn't implement it, and I don't expect we will. I don't know of any plans to remove it from Gecko, though I'd personally be happy to see it go. |
|
There's also What's our timeline for removing |
|
Paging @smaug---- and @overholt for Gecko plans. |
|
I think at our last check the only open issue was if there were any obscure parsing rules that would have to remain. Was Chrome able to remove it without any consideration for retaining parsing logic? My simple tests show that parsing logic shouldn't be an issue since, but we have some legacy code, which I have to verify is dead, that would have a difference. I believe this is only there for the pre HTML 5 parser of which portions still exist. @travisleithead to track the issue from our end and provide back status |
|
I think I answered my own question. Chrome kept the parsing rules, https://jsfiddle.net/akqv85z5/, since the result of this should be italic unless special |
|
Yeah, there was blink-dev discussion on the parsing, and the decision was to keep the parsing rules, as has been done for other elements like bgsound. |
|
So does anyone have any appetite for getting rid of |
|
I tend to think we should just lave it alone. |
|
Ideally someone should at least use-counter it... Blink has already gotten rid of a whole global interface (HTMLAppletElement), so I can't imagine this being that bad. |
|
Removing Quick GitHub search: |
|
Yeah, removing document.applets won't save much code or runtime memory, so the motivation for removing it is almost for sanity, as Java applets have (or will be) gone. BTW, Blink still counts |
|
I found this overall odd. That an |
|
Ah, I had not realized that Chromium would not include
AFAICT Gecko matches the spec. So I see some options:
Any opinions? As for the other collections, if it hasn't caused trouble for Chromium to not include |
|
If it can't be safely removed, then the current spec or an empty collection seems like the most sane options. @TakayoshiKochi has added use counters in https://codereview.chromium.org/1883433003/ which should tell us something. |
|
I think maybe people have lost the context of this thread. We're talking about what to do with |
|
@domenic there's a third, continue to return |
|
Oh, I see, even if their interface is HTMLUnknownElement, we'd return them. Yeah, I am OK with either that or empty or missing. |
|
I know of no Gecko plans here, either. |
|
FWIW: per http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4217 Blink always returns an empty So here is my proposed change:
It seems like we're waiting on implementer movement on this. I filed https://bugs.webkit.org/show_bug.cgi?id=157926 on WebKit to see if they're interested. So far I count:
|
|
Once the change is made to the spec, I'd send intent-to-remove "counting |
|
I don't believe Edge has made any of the changes discussed so far, but I do not have an Insider Build of Edge to test. @DigiTec? |
|
Yes we are still interested but have not started. Most of my work has been focused on the various collections convergence where edge had a lot of issues relative to the other browsers. We'd probably make this series of changes early in our next release and then flight it out. I hope this would be fast enough so we can achieve this convergence. |
* 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.
|
PR to remove |
* 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.
|
I guess we're waiting for one more engine to remove before dropping this from the standard? |
* 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.
|
Is this supposed to still be open? |
|
Yes. |
|
As I commented on https://bugs.webkit.org/show_bug.cgi?id=157926, I don't think we're dropping the support for |
|
Good to know, thanks. I think it's still a good idea to remove it from the spec since it's on the verge of becoming a Safari-only feature. |
Despite wanting to agree with you, i know some France public service websites which require to use java applets. It's becoming trickier and tricker to access them ("i have a friend who has a windows XP"-type of trickier). One of these is a website for companies to apply to government contracts (with some Symantec garbage certificate usb flashdrive thing). It was interesting to learn that Safari cares enough about Java in this thread; the website recommands IE6+ or Firefox 4+ (lol), wondering whether they test with newer browser and Safari in particular. I want to see Java die on the web but i think this currently breaks the web :-( the wab no one likes, but the web anyway. It doesn't make things worse than they are today, but Safari-only also means no linux. |
|
If only WebKit supports it, they'll be forced to update the site to not require Java, because WebKit doesn't run on Windows. There don't have to be zero sites supporting it for us to remove it. |
|
Well, I'd imagine that many of those websites that rely on Java are enterprise softwares, in which case, they'd recommend using Internet Explorer on Windows. |
|
The first comment says Edge is willing to drop support, but I guess they could still tell them to use IE in compatibility mode. Nevertheless, I don't think such sites are a great reason to keep the feature, if there are only a few. If Chrome and Firefox already removed it and are willing to stick with that, that's a pretty good indication there aren't loads of sites using the feature (unless they're WebKit-only). |
|
To be clear, Java applet support is already removed from Edge. They haven't done all the changes proposed in #1399, probably because it didn't exist at the time they were making the decision. But once Firefox lands their removal, Java support will be a Safari-only feature, and thus not have a place in the HTML spec per our working mode. |
|
Firefox landed their removal already for 56, which is currently beta and is due to be released as stable on September 26. |
This removes support for the applet element from: * document.all[name] * document[name] * window[name] Furthermore: * document.applets now returns an empty array * Removed handling for applet elements in <iframe sandbox> * Removed rendering rules for applet elements * Removed the element itself and HTMLAppletElement * Applet elements now use HTMLUnknownElement The HTML parser is intentionally not changed. Tests: web-platform-tests/wpt#6684. Fixes #454.
This removes support for the applet element from: * document.all[name] * document[name] * window[name] Furthermore: * document.applets now returns an empty array * Removed handling for applet elements in <iframe sandbox> * Removed rendering rules for applet elements * Removed the element itself and HTMLAppletElement * Applet elements now use HTMLUnknownElement The HTML parser is intentionally not changed. Tests: web-platform-tests/wpt#6684. Fixes whatwg#454.
In #75 we deprecated
<applet>. We should consider removing it. Blink has done so and Edge has said they are willing to do so. Is that sufficient, or should we wait for more? Are there tracking bugs for removing it from other browsers?The main removal here is of HTMLAppletElement, but there are also other places it shows up, e.g. in the window named properties, or
document.all.The text was updated successfully, but these errors were encountered: