I remember fights over whether or not navigation in frames was bad practice. Not iframes, frames. Who here remembers frames?
I remember using HTTP 204 before AJAX to send messages to the server without reloading the page.
I remember building... image maps[1]... professionally in the early 2000. I remember spending multiple days drawing the borders of States on a map of the country in Dreamweaver so we could have a clickable map.
I remember Dreamweaver templates and people updating things wrong and losing their changes on a template update and no way to get it back because no one used version control.
I remember <input type=image> and handling where you clicked on an image in the backend.
I remember streaming updates to pages via motion jpeg. Still works in Chrome, less reliably in Firefox.
I remember the multiple steps we took towards a proper IE PNG fix just to get alpha blending... before we got the ActiveX one that worked somewhat reliably... Just for tastes to change and everything to become flat and us to not really need it anymore.
I remember building site navigations in Java, Flash, and Silverlight.
I remember spacer gifs and conditional comments and what a godsend Firebug was.
I don't know when I got old, it just happened one day.
1. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
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.
6. Analytics is harder to track.
>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.
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.
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.
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.
Idk if that counts as a low point or a high point.
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.
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.
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.
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.
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.
Now I am micromanaging a LLM that gets to do the fun parts. I have become the middle management I always hated.
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.
For those who doesn't know the ASP.NET update panel was basically HTMX before HTMX. The browser would do a background request and replace the content of the update panel with the html returned by the background request. Normally you'd just use if for a form submit, e.g. like a comment box. The user puts in their comment, the backend return all the comments, including the new one and the browser replace the current list of comments with the new one. We essentially put the entire site in to the update panel.
https://www.htmlgoodies.com/css/how-to-create-sliding-doors-...
To export gifs meant to be positioned perfectly in HTML tables
For designs suited best for 800x600
All those moments lost in time, like tears in the rain
I made so many newsletters using that tool back in 2009. I remember a new designer was appalled I used it, and did not write the HTML code manually... 70% of our receivers were using Outlook and the horrible Word-based HTML renderer. I'm not writing anything manual for that piece of crap.
And then I remember the slice tool appearing one day and being equal parts annoyed that they were biting my style and amazed that they did as thorough and well considered of a job as they did.
I visit a site with frames several times a week. Nobody's ever told the Open Group/POSIX people they're not supposed to use them these days.
What is the motion jpeg hack? I made my own streaming too before websocket... but I never heard of this.
Low value comment: ME!
Bonus - Server Side Includes changed my life.
I recall, in about 2010, hiring a young engineer to help with small marketing pages at an agency in New York City. His work was pixel-perfect at a time when we’d spend days just trying to get things looking reasonable in IE6. He was fast. It was incredible.
He was gone for the day when a last-minute change came in, so another dev went to update his latest work. Turns out he had been exporting the entire designs (from Photoshop, of course, no Sketch or Figma back then) as a BACKGROUND IMAGE and then ABSOLUTELY POSITIONING form fields.
I thought it was brilliant. No one else but the boss agreed. Testing for all of his work had been flawless cross-browser. It just didn’t work well on mobile. But he didn’t have to center things in a div - it was all smoke and mirrors.
I miss those days sometimes.
I remember writing image maps by hand, getting the point coordinates directly from the image in Photoshop.
Re version control: learned very early on to make a backup of a website before making any changes. Our version control was /site/yyyymmdd/
To us, it sounded like: fjänfny, hmmhmmhmm, dadadada. I only realized lately that the first word must be "bienvenue". It would be amazing to find it again on archive.org but unfortunately I dont remember more than this. :)
I was there, writing sites professionally when this was rolled out.
They're more or less deprecated, but I missing having a 1st-class building block that allows you to resize areas of the screen. Recommendations are to use anything but a <frameset>, but there's no replacement for that one feature.
> I remember building site navigations in Java, Flash, and Silverlight.
Don't forget ActiveX (actually, yes, we should all try to forget)
Don't worry, they are still alive, the swedish crime statistics website still uses them [0]. It's a great experience for everyone.
Hacker News actually still uses these for comment indentation, check this page’s source code.
I find it helpful to test for HTML injection vulnerabilities because marquee moves, and it's a tag that (almost) nobody intentionally uses, making it easy to identify when an attack works.
I also find it helpful to show non-technical people the effects of HTML injection, because, again, it moves. "This moves and it really shouldn't move" is something people understand better than "this text is bold and it really shouldn't be bold."
Also: I built the thing, so maybe I should fix it some time.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
> from The Book of Mozilla, 12:10 (about:mozilla)
And now Mozilla is being scorched to the earth. The End.
Seamonkey is pretty much the descendant of the OG Netscape Communicator codebase. So it's kind of on topic for retro Web stuff.
They were initially Netscape, a commercial company, so they had money from their customers.
After the browser code base was handed over from Netscape/AOL to the Mozilla Foundation in 2003, they got donations from AOL, IBM, Red Hat, etc. which kept them going for a few more years.
The Mozilla Foundation signed the deal with Google two years later, in 2005.
In short, they survived first on commercial revenues and then from donations, neither of which are substantial now.
However, with that over use, people were giving HTML a go. For someone new to writing HTML, it was very rewarding to be able to use <blink> or <marquee>. These were the gateway drugs of the HTML world, and, anyone that used these elements would eventually learn not to, or maybe not, if it was their mySpace page.
It is easy to hate on the <blink> and <marquee> elements, much like how every snobbish graphic designer can chortle about stupid people using Comic Sans, however, all of these no-no's had great utility in giving people confidence to give things a go.
No 20mb js framework, no ide, no ai "assistants", just pure, healthy, free range basement grown webpages the way god intended.
My magnum opus was a Flash site, that looked like a blank black page, and revealed the page structure, in a fuzzed circle, as you moused around. It was, literally, a flashlight in a dark room interface.
You could probably do the same, these days, with CSS. Back then, you needed Flash.
The space must flow…
I don’t know if it’s the state of development in the country as a whole or just the lowest bidder for a government service problem.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
And not just to be another neocities.
There's so much lost joy and wonder to recover.
Sincerely, just do what you love with it, don’t market it.
What's missing about the retro experience is browsers and computers were slower back that then, so large marquees would blink and scroll with visible tearing.[0]
[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
[0]: https://bradlyfeeley.com/ (no idea which browsers it renders properly in)
I never figured out why the actual <marquee> tag has a low frame rate. Maybe it’s to make it more unpleasant so you won’t want to use it. Certainly I would use a CSS animation instead for the frame rate reason, if I was forced to put a marquee on a page.
Playing with the scroll speed makes it feel smoother:
<marquee scrolldelay="50" truespeed>scroll faster than default</marquee>All the code in that file is a fun read. <marquee> was rewritten as if it was a web component using the public DOM APIs (ex. It uses CSS animations and requestAnimationFrame).
Blink was used almost entirely for annoyance value - in other worse, all its uses were annoying. Marquee was the slow news ticker at the side you could ignore if you wanted to.
Did that on my first day of college, inside an .hta file for windows and blew my classmates minds. #hackerman
I think some people just want to feel important by diminishing things they see others diminishing, makes up from not having thoughts of one's own.
This applies to everything, not just HTML obv.
It doesn't matter if it's a scrolling marquee, an animated gif, some Flash, a movie, a popup, a cookie banner, etc...
Generally, moving/animated things grab your attention and people find it annoying.
What do you mean by "on the web, there is no space limit"?
If you're talking about the interface by which we consume the content, I use a screen whose dimensions are finite. What do you use?
here is the German version: https://x.com/K0IN1/status/1025459517499367425
However, thanks to the brilliant hard work of the open source community, we have a widely supported browser polyfill: https://github.com/yocontra/blink-polyfill
https://web.archive.org/web/20250608044216/https://danq.me/2...