It is almost a shame modern browsers no longer support all the fun layout patterns of ol' FRAMESET. There was a layout tool to cut your teeth on (possibly literally the way it was made out of browser chrome).
Not that I necessarily advocate for frameset insanity, but you know what? That is a shame. My controversial (?) opinion is that browsers should literally never break anything that was once a part of the web platform unless there's simply no other choice. If the size of it is getting too big... first, stop adding more shit. (And then maybe, implement some old features in terms of some newer ones. Not really "web platform" but I am a huge proponent of what Ruffle is doing for the web.)
I’ll go a step farther: improved frames and datasource-aware tables and lists with a few very basic features found in almost any other UI kit out of the box would have given us 99% of the actually-beneficial stuff AJAX did, but better.
The Web is a ton worse because we decided to build apps on it but never built the tools to do it right, even though the building blocks were right there.
IMO the biggest problem with the way frames works is that it doesn't work well with navigation. I think unfortunately that this is just a design flaw with frames and it needed breaking changes to mitigate.
I think I would've rather seen it go that direction, but it's hard to say. Without a crystal ball, we can't really compare the outcomes, and it's hard to imagine what would've happened in this hypothetical. I mean, I don't think in 2004 I would've been able to guess (or stomach) what the web was going to become 20 years down the road.
I can't agree with this, because it creates a "barrier of entry" for people building new browsers. Old things should deprecate when new things do them better, and deprecated things should phase out.
Otherwise, we're stuck with Chrome Forever. I'd rather not.
Disagree. Deprecating things like <frameset> will not make it easier to build new browsers. Shadow DOM and WebComponents are significantly more complicated for browsers to implement than any old "deprecated" technologies. If you don't want Chrome forever, what you want is not removing old technologies, it's preventing more new technologies from becoming a part of the web platform.
We'll get better at building software. Even with huge engineering teams, we can only build the browsers that we have today due to improvements in large-scale software engineering.
Framesets still work as far as I know, they're just no longer recommended for a few reasons. Browsers already try very hard to never ever break anything, at least not anything that's been commonly supported for years or has made it into a standard. The main places browsers have broken compatibility with old content are related to plugins like Flash and Silverlight, which were always controlled by a single vendor instead of being open standards.
> at least not anything that's been commonly supported for years or has made it into a standard.
It's more: has made it into a standard and was commonly supported.
Sadly, the browsers aren't trying hard enough not to break anything. They are trying hard not to break anything standard, but the problem with that is that the standards can change, or that some things can be claimed to never have been standards all along. A bunch of IE/Netscape things have broken already such as BLINK and MARQUEE, despite being common enough to "feel" standard even though yes they were never actually standards. Also, as we've seen with the MathML battle in recent years, even standards aren't guaranteed to be kept in browsers if not "commonly supported".
The MDN deprecation warning on FRAMESET:
> Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes.
The browser support table says that every browser still currently supports FRAMESET with simple COLS and ROWS, but as I recall FRAMESET used to also support more complicated layout tools. My brain recalls it as being very similar to TABLE layout at one point in time that you could also have (limited) COLSPAN and ROWSPAN options. Such things may also have been IE/Netscape era "non-standards". If I had examples, they are probably lost to time. Similarly, with nearly no way to easily search in today's indexes for things specifically from the 1990s I can't think of a good way to find old examples either. It's also possibly my memory is just failing me on this and the crazy things I recall doing with framesets were just table layouts after all and maybe iframes, but I do recall doing some crazy things in the 90s that certainly aren't "standard" today and I know wouldn't work in today's framesets.
Yeah I don't really count Flash or Silverlight as parts of the "web platform" personally, though I will re-iterate that I am still very pleased with the Ruffle project nonetheless. From a practical standpoint, Ruffle does a lot of good even if Flash always was proprietary and not really a part of what the web platform really was at its core.
I hope <frameset> continues to work into the future. I'm sure eventually it will wind up on the chopping block, and personally I think that'll suck.
Although there is some degree of silliness to suggesting table layouts in 2024, it frankly really is not that bad. To me personally, the era of float: left and clearfix and 10 layers of wrapper divs was significantly more of a mess. "Oh look, I got my layout working on IE6! Oops, it's now broken in Opera..." Anyone remember using invalid CSS to write browser-dependent styles? How about using Microsoft's proprietary DirectX filters to make PNG transparency work? In the era of taking crummy PSDs full of graphics and chopping them up into images for an HTML template, these were the tools of the trade.
Not that tables were perfectly standardized or anything, because I do remember Netscape and IE not totally agreeing on how to handle column widths, but they sure were, well, simpler.
Yeah, but HN uses tables in a really dumb way. Each comment is in a separate table with the width of the first column set to provide the correct amount of indenting.
If the comments were properly nested you would just have a standard left margin and the tables would be completely unnecessary.