Hacker News Reader

Comment by chrismorgan | Hacker News Reader

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.)

View on HN

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.

Reply on news.ycombinator.com