
you don't need framesets bruh
Written: 2025-09-05
Prior to this week, I'd never used HTML frames myself; I'd heard the old story about how they're deprecated, and had never bothered to look further into why.
But then in my interwebz surfing adventures, I happened across the GIF you see above. It was created by a fellow indie webmaster, the talented Ms Lulu. Practicing what she preaches, her website very prominently uses HTML framesets.
Her point about accessibility resonated with me; much of the web infrastructure of today prioritizes the interests of professional web developers and, by extension, their employers. This is made clear with incidents such as client-side DRM getting officiated as a Web Standard by the W3C, over the protests of open-web activists.
but whyyy
That being said, framesets were not deprecated for no reason. Even prior to the browser vendor mutiny that birthed HTML5, W3C's own XHTML 1.1 entirely removed support for framesets.
Besides the basic issues of search engine–indexability that no doubt were a keen motivating factor in the industry's push to axe them, framesets also cause problems on the user's end.
The browser's "back" button breaks, bookmarks don't actually link to where you intended, scrollbars clutter the screen — not to mention the sacrifice of accessibility for those viewing the page via alternative means, be it on paper or through a screenreader.
Frames are remarkable in being one of those technologies that had such glaring deficiencies as to be consensually hated by the public at large. Today, its ranks have been joined by the likes of Adobe Flash (and perhaps tomorrow, WebP).
Are the drawbacks really worth the supposed ease of using frames?
we have grids now y'all
CSS has advanced very far since the days of Netscape Navigator 2.0. The CSS grid layout module – supported in all major browsers for the past decade – makes it delightfully simple to partition a box into neatly-organized subdivisions.
A page layout that was once so unattainable it was dubbed the holy grail of web design
can now be implemented in less than a dozen lines of code, without the need for any JavaScript.
I invite any amateur webmaster to inspect the source of this page to behold the simplicity of the style rules that can produce such a layout. I reiterate that this is possible without needing to resort to frames or even HTML5 iframes, whilst maintaining accessibility and semantic significance with the use of HTML5 semantic markup tags such as <aside>
and <main>
(as well as ARIA attributes when necessary).
so uh like yeah
I submit that HTML frames do not excel in ease of application and maintenance as compared to modern CSS.
But even if they did (which they don't), the degradation of the user's browsing experience, the lack of support in modern authoring tools and the unreliable browser support, both new and old, nevertheless make it an unjustifiable technical decision.
I suspect on a more fundamental level it is inappropriate to stitch together a single page out of multiple tiny pages. If distinct content warrants being on a separate page, then let it be on a separate page, rather than have it permanently be on screen yet simultaneously inaccessible.
but who gaf
I don't expect much of the above to comprise a compelling entreaty to the capricious indie-web pioneer. I understand that part of Web 1.0 revivalism is the revival of old techniques of web design: GIFs, marquees, and raster buttons are indispensible, and I wouldn't have it any other way.
And let me be clear: frames are pretty cool! I've always adored the angle-bracketed beauty of markup, whether with or without frames.
But it would behoove us all not to disregard tout court the innovations of Web 2.0 (or even 3.0!) without rational assessment. The advancements of the past 20 years can be held onto while understanding and criticizing the corporate web in which they emerged.
For Delta.
addendum
Written: 2025-09-07
I have received feedback from readers expressing apparent confusion with respect to the difference between frames and inline frames.
Frames use the <frameset>
and <frame>
elements. They were invented in the late 90s, originally by Netscape and later reimplemented by others. This functionality was standardized in HTML 4.01, but deprecated in HTML5. Webmasters cannot rely on browsers to implement them consistently, correctly, or at all.
Inline frames, on the other hand, were introduced in HTML5 as the intended substitute for frames. These use the <iframe>
element.
The difference is that inline frames are, well, inline. Instead of a frameset comprising the entirety of the document, inline frames are regular boxes nested squarely within the HTML body. They are by design not intended to comprise the entire layout of the parent document, as this is not considered good practice for reasons already stated; instead, they should be used for an embedded HTML page that absolutely must be external (such as a map embed from another website).
what about fencedframes?
Fenced frames, which use the <fencedframe>
element, are a new experimental technology being worked on by our Google overlords. It seeks to address security issues associated with inline frames by restraining script communication between framer and framee, prisoner's dilemma–style.
As of writing, fenced frames has yet to see anything close to widespread feature-complete implementation in web browsers, including Google Chrome. The draft specification has yet to even be considered merging into the mainline HTML standard, though it's probably just a matter of time.