This looks to be an interesting series; too often it’s really hard to find out what something once was. Some of the articles are about things that have been removed (like <keygen>), others are of things that are still actually there, though no one uses them any more (such as server-side image maps).
I hope one is written about <ISINDEX>. That element really confused me when I was young and it was already thoroughly on the way out (though I can’t remember whether it had quite been removed yet).
For something like this, remarks about the site itself can be fair game. Here’s an interesting one: the site actually uses XML syntax, something few realise is even possible these days, but which is rather interesting in its differences and incompatibilities. (Some affect authoring, e.g. whether <, & and > must or must not be entity-encoded inside <script> and <style>. Others affect runtime, e.g. many JavaScript libraries assume Element.prototype.tagName is uppercase, but it’s not in XML syntax.) Probably my favourite thing about XML syntax is that it lets you nest links (though it’s nominally invalid), which can’t be done in HTML syntax (though you can do it in a live DOM using JavaScript).
Author here - yes, ISINDEX is on my radar. ;) Taking other suggestions also - I'm sure my memory isn't exhaustive. At some point I may venture into the weird proprietary extensions IE had also.
Of regular HTML features, one more immediately springs to mind: <frameset>. It’s similar to image maps as a feature that still works, but which no one uses any more.
(I actually used <frameset> for fun a couple of years ago in a live-coding-completely-from-scratch demo/talk that I prepared roughly but have never actually delivered, entitled “building a fair dinkum email client in half an hour with JMAP”. I was mildly surprised to get the frameset right without looking up any docs, despite not having used it for well over a decade, and not much before that.)
Hmm… maybe <plaintext> and <xmp> too, which still have fun parser implications. No idea how much actual use they ever got. (For that matter, I’m not sure how much use ISINDEX got.)
Yeah. Of course, nowadays I believe you could replace <frameset> almost entirely with iframes and CSS layout. But it does occur to me that there was exactly one feature of frameset which you maybe can't replicate: the ability of the user to resize frames with the mouse without relying on JavaScript.
...Although, come to think of it, the CSS `resize:` property exists now, and it seems it can be used to make arbitrary elements resizeable. Might actually work for it, though the UI might differ a bit.
There are differences between browsers in how they handle frames and history management (e.g. if you reload, Firefox keeps the iframe source documents as they were at the time of reload, since Firefox likes to retain stuff across page loads, and generally does an excellent job of it, but occasionally what it does messes with what the page tries to do if they aren’t aware of Firefox’s superior handling; Chromium, by contrast, does what it does so well, and throws it all away and starts afresh from what the source document specifies, which is actually a bit baffling given that frame locations are actually a part of the history entries so they could easily do better in at least most cases).
But I don’t think there are differences any more within a single browser between how frameset frames and iframes are handled, for history purposes. I vaguely recall seeing some of this stuff being specified in the HTML Standard maybe last year or so. I suspect there used to be differences, but I’m not confident.
As for CSS resize: for consistent support, you’d need to have the iframe fill a div, and make the div resizable. (As the spec says <https://www.w3.org/TR/css-ui-3/#resize>: “Applies to: elements with ‘overflow’ other than visible, and optionally replaced elements such as images, videos, and iframes”. Firefox doesn’t currently support resize on replaced elements. Fortunately the workaround is straightforward, and reliable so long as you’re not having the elements’ intrinsic sizes influencing layout.)
As for its UI, current consensus gets you a grippy in… well, roughly the bottom-end corner. (It depends on direction and writing-mode, as it should, but some of the choices seem moderately arbitrary since they’ve obviously decided to anchor it to one of the bottom corners, and while Firefox’s placements all seem sensible enough, Chromium gets the position obviously wrong when you combine direction rtl with writing-mode tb, tb-rl or vertical-rl; I should probably file a bug for this, but I’m too lazy.) Anyway, just a regular corner grippy for `resize: horizontal` or `resize: vertical` is rather disappointing. Need some way of controlling it to say “make it a full interactive border”.
All up, it’s nowhere near as simple as <frameset> if that’s exactly what you want, and its UI is a bit wonky, but yeah, it pretty much works, and it does give you a lot more flexibility.
From what I can tell isindex was some kind of search element designed to search the contents of the current page, via the server? A bit like the <input type="search"> of today? Would you say this search I have here is similar to isindex? https://www.lloydatkinson.net/articles/
Touching on both link nesting in HTML, and obscure elements, this blog article (https://www.kizu.ru/nested-links/) give a quite interesting approach of using the <object> element.
I believe you can also use SVG’s <foreignObject> to jam all sorts of things into hierarchies HTML and browser DOM doesn’t usually permit. And of course with custom elements + shadow DOM, the rules are only as restrictive as your imagination.
I hope one is written about <ISINDEX>. That element really confused me when I was young and it was already thoroughly on the way out (though I can’t remember whether it had quite been removed yet).
For something like this, remarks about the site itself can be fair game. Here’s an interesting one: the site actually uses XML syntax, something few realise is even possible these days, but which is rather interesting in its differences and incompatibilities. (Some affect authoring, e.g. whether <, & and > must or must not be entity-encoded inside <script> and <style>. Others affect runtime, e.g. many JavaScript libraries assume Element.prototype.tagName is uppercase, but it’s not in XML syntax.) Probably my favourite thing about XML syntax is that it lets you nest links (though it’s nominally invalid), which can’t be done in HTML syntax (though you can do it in a live DOM using JavaScript).