I developed web software with frames and I thought it was perfectly fine. To this day I still don't understand the issue with frames. People sometimes mention accessibility for screen readers, but nothing more specific than that, so I still don't know what the actual problem is.
> so I still don't know what the actual problem is.
1. Not adaptable to the variety of display form factors we have today. In other words, not responsive enough.
2. As others mentioned, not being able to link a specific page. Maybe it can be overcome with modern browser history replacement API's nowadays.
3. A link to one of the frames not opening with necessary navigation elements. That used to be solved by redirecting the user to another page that would decorate the same page with the frames around it. Quite cumbersome.
4. Since all frame components are individual web pages, the communication between them isn't straightforward except for opening a link in another frame. Programming more complicated logic (such as dragging from one to another, or sharing components in other ways) would be quite difficult.
5. Every frame has its own scrollbar. It's less accessible, and looks terrible too.
If you right click a link and open in new window (or middle click), the frameset was gone and only the piece in the frame was visible. Also you could not bookmark anything. I remember doing a frameset per content frame url automatically and also redirecting to that frameset from inside the page via javascript if the content frame's url was directly opened.
>If you right click a link and open in new window (or middle click), the frameset was gone and only the piece in the frame was visible.
Feature, not bug in my book. Same thing happens in today's iframes. But for situations where that is a problem, the spec could have been extended to support every page being able to identify a preferred parent frame. Or browsers could have changed behavior to by default duplicate a frame's parent and siblings when opening a frame in a new window.
>Also you could not bookmark anything.
Again a limitation of the spec that could have been addressed rather than throwing out a useful feature. We support have text fragment identifiers in URLs these days; surely we could have supported URLs with multipart frame targets.
They could! window.parent exists for this! Also, the target attribute on a.
For multipart frame targets, the fix then, as it is now, is to parse out the URL fragment params into something reasonable. SPAs use the path for state; no reason you couldn’t use it for frames.
If browsers got around to actually implementing basic features on browser level like making a frame navigation work instead of coming up with new CSS properties that nobody is going to use we could be all building websites without any javascript.
It generally got a bad reputation because it was abused to keep people on portal-like and aggregator sites. These sites would parasitically add navigation banners and ads(!) to content they didn't own. You had to be somewhat web-savvy to know how to escape an annoying frame.
They also wouldn't fly these days because of CSP and general web security.
When Google Image Search first launched, it surprised people because they found a legitimate use for frames that wasn't user-hostile.
Frames also broke the back button when they were first introduced!
Together with the other early problems - ugly borders, proliferation of scrollbars, and limited browser compatibility - it meant that frames were seen as a usability disaster right from the start.
They never managed to fully shake that reputation even as browsers improved in the later 90s.
That ship has long since sailed. We live in a world of web apps with dynamically created content, AJAX, and so on. The main entry point for the app has a URL, and then within the app all bets are off. Same with framesets.
We should have frozen the web from 2006 - 2010 or so.
We had Ajax, lots of modern CSS, but weren't hell-bent on CSSifying and "SPA"-ing everything. Web standards hadn't yet jumped the shark.
It's also before Steve Jobs murdered Flash.
Killing Flash was one of the biggest mistakes we've made. The modern HTML/CSS/JS stack can't replicate how simple and functional it was. We're easily dealing with 100x the complexity now.
We let Google trick us into going down this path. And now they're going to kill the web to keep us on their LLMs and platforms.
> Killing Flash was one of the biggest mistakes we've made.
Flash was a proprietary extension to the Web. That important parts of the Web were implemented with it was a travesty and reason enough for it to be killed as it threatened and subverted the open nature of the Web. The useful functionality it provided has been incorporated into Web standards and current implementations are no more complex or less efficient than Flash was. The rest is fluff which can readily dispensed with, there is no need to re-implement it, although lately I have been wondering if it is possible to replicate its functionality with a combination of SMIL and SVG.
Flash was a bigger privacy hole than HTML5 canvas. I think we need to mandate browsers that block those APIs on default and only enable them via permission. <canvas> is often used in fingerprinting. So blocking its introspection APIs would already benefit us.
Flash was basically a remote shell with some animation tools on top. The Windows malware hell of the early 2000s, with random websites (even a banner ad on the New York Times once) doing drive-by-installs of early ransomware. (Thankfully, cryptolocker ones hadn't started yet...) And if you were a Windows escapee, the Flash experience was absolute trash on OS X and Linux.
It also became clear that the source code was borderline unmaintainable and/or Adobe lost everyone who knew or cared about it after they bought Macromedia.
That sounds like a big deal until you realize that nothing was private back then.
Most internet traffic wasn't even over SSL. It wasn't enforced until 2018!
No CORS (first standardized in 2014), no cross-site protection (first standardized in 2012).
Everything was the Wild West.
Flash was fine and could have adopted the same mechanisms.
If Adobe (or the earlier owners) had open sourced the player and the format standard, they could have won and had the best authoring tool for the format.
To this day, Flash is the only downloadable binary bundle format that can still run on your PC after being downloaded. You can't download and SVG animation. It's a bundle of brittle web tech slop.
> No CORS (first standardized in 2014), no cross-site protection (first standardized in 2012).
This is not correct. CORS doesn’t protect anything, it removes security barriers. The same-origin policy that stops cross-site requests goes back to the 90s, it’s been in there about as long as JavaScript.
Adobe killed Flash by letting it die. It had plenty of issues, none of them unfixable. Adobe didn't fix these issues (security, accessibility,...) all while keeping everything proprietary. It was unsustainable and unfortunately, Flash had to go.
Frames had multiple UX issues. For example they didn’t work well with search engines. Since search engines indexed individual pages, the search result would link to the page without the framing. Some developers would counteract this with js contraptions which reloaded the frameset, usually losing the context and breaking the back-button.
I paid for 1024x768. Because of your frames, the content I'm actually interested in is now restricted to some disgusting and dismaying fraction of that. The borders of my bitchin' 15" CRT are now committed to navigation (which I have to scroll horizontally to actually make sense of) and what is likely a LinkExchange banner on the bottom that adds absolutely nothing to my experience.
