<ISINDEX> support was removed
Reported by
dpken...@dpk.org.uk,
Nov 25 2015
|
|||||
Issue description
Chrome Version : 46.0.2490.86
OS Version: OS X 10.11.0
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 4.x:
IE 7/8/9:
What steps will reproduce the problem?
1. Go to http://www.archives.nd.edu/cgi-bin/words.exe
2. Observe that there is no input field where the isindex is in the source code
3. Be sad
What is the expected result?
Ability to search for Latin words in the above-linked dictionary.
What happens instead of that?
Can't.
Please provide any additional information below. Attach a screenshot if
possible.
UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36 OPR/33.0.1990.115
,
Nov 26 2015
,
Nov 26 2015
Here's where we discussed removing this: https://groups.google.com/a/chromium.org/d/msg/blink-dev/14q_I06gwg8/0a3JI0kjbC0J Sorry. The consensus was that ISINDEX should be removed, despite that breaking some sites.
,
Nov 26 2015
@erikchen: This used to work, it was removed; see eg https://codereview.chromium.org/96653004/
,
Nov 27 2015
This is a troubling precedent. Is there a single other 'early HTML' feature which has been similarly dropped? Will FONT be deleted too some day? These features are important for accessing historical websites. Note that Chrome is willfully violating the HTML parsing algorithm here, which states that any ISINDEX tag should be replaced with an equivalent FORM.
,
Nov 27 2015
I believe we considered these kinds of issues in the thread Dominic linked above. I don't believe a slippery-slope is something to worry about in this specific case, as the rationale for removing `<isindex>` was based on security-relevant modifications to the parser. `<font>` doesn't have those same concerns; in fact, no other HTML element has those concerns. Removing `<isindex>` allowed us to remove the "pretend that this token is actually this other series of tokens" machinery from the parser entirely.
,
Feb 1 2016
Please put <isindex> back. If the way you were implementing it (a fake form) was broken then implement it differently. You're just making your life easier at the expense of people who have old scripts who will have to rewrite them -i.e ME.
,
Mar 19 2016
Ditto that. We now have three URLs which people have been using for a long time (since the 1990s) which have, in the eyes of non-technical users, become mysteriously broken. I have been using the words.exe online interface linked in the original issue since 2008, when I started learning the language (at that time, I didn't even know what <ISINDEX> was). marc.men...@gmail.com pointed recently in that threat to two other pages, also around since the 90s, which he has also presumably depended on since then. Let me ask this: has there *ever* been a single security vulnerability in Blink related to how the HTML parser handles <ISINDEX>? Or in any other browser? The WHATWG specified <ISINDEX> as a special case of <FORM> specifically to make its implementation easier while remaining compatible and secure, as I understand it. I realize that my argument was a slippery-slope, and your response did little to satisfy my concerns. In the future, will it be: "removing <FONT> allowed us to remove the 'pretend this element without CSS attributes actually has styling' machinery from the renderer entirely"? This has caused a serious dent in the trustability of the Web as a long-term platform. I will note that every single WHATWG person who participated in the threat said this was a bad idea. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by erikc...@chromium.org
, Nov 25 2015