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.
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.
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.
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.
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.
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.
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.
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.
I remember working for a client who needed to support IE6 (with all the insane bugs/quirks/limitations) and I’d despair every time the designers would hand over a Photoshop design with rounded corners. They also needed it to be responsive (at the time mostly just different desktop sizes). Would usually require cutting the corners out and positioning them in table cells. There’s a certain amount of dev resilience you build having to do stuff like that by hand!
We worked with an internal design team, but basically just one UX specialist who has zero comprehension of how HTML, CSS or and web related technologies worked. At one point we where meet with "I don't like that the site blinks!" ... What do you mean by "blinks", we built it, it doesn't blink. Turns out she didn't like that that switching pages would cause the browser to load the next page and in turn there would be an ever so brief moment where the browser would show a blank page while loading the next page. This was in the initial ASP.NET and Ajax days, to the end result was "wrap the whole damn thing in an update panel".
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.
Even though it was a long time ago I still have IE6/7 workarounds burned into my brain, most of them float related but also having a whole stylesheet for that damn browser... <!--[if lte IE 6]>:
> I remember meticulously using the photoshop slice tool
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.
I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-Beams glitter in the dark near the Tannhäuser Gates. All those moments will be lost in time, like <blink> and <marquee>.
I made a webchat with frames; an infinitely-loading top part for the text, and the bottom an input box that received 204 to not reload when you sent a message. I guess that was the most elegant way to do it in the IE4+ days.
The top part could also receive a small <script> that would reload the frame on the right, containing the user list. Fun times. Used it with a couple class mates around 2000 iirc.
I managed to get real-time chat (and other real-time colab) working on IE4+ using long polling, by continuously adding <script> tags from JavaScript. The server would delay answering until there were new messages available, or some timeout. This was even before xmlhttprequest. Who needs websocket? :-)
Sounds fancy! My solution back then was infinitely auto-updating a frame with a meta refresh tag. It would receive a new <script> block that would update the contents of other frames. This of course wouldn't give real-time functionality.
I remember a website about Ski-Doo snowmobiles that my friend was obsessed about (both the website and snowmobiles) in 1998 or so. It was from Canada, and the bgsound was the website owner saying something in French.
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. :)
Don't know if it was intentional, but your ramble reminded me of the lyrics of Losing my edge by LCD Soundsystem. However, as someone who also experienced most of this stuff, it was a fun read either way :)
For those who prefer not to visit yt, the quote "I was there, Gandalf. I was there three thousand years ago" refers to Elrond talking about the time when Isildur took the One Ring from Sauron.
Ahh, good times. I ran a "college dorm floor" website off my computer for a while and included a 997-word marquee on it, just rambling and talking about girls, depression, and philosophy. At the very end there was an exclamation point that was a href to a hidden page. Of course, someone hit view source to read the stupidly long message and found the page anyway.
I created this a while ago, and whenever I show someone they are shocked to see there is absolutely no JavaScript; all of the animations are done via marquee tags: https://udel.edu/~ianozi/
I probably haven't looked at the marquee tag in 20 years, so I could have just forgotten, but I was unaware it has a direction parameter to allow for vertical scrolling.
My favorite trick with <marquee> was to nest them, with different, alternating directions. You could make the contents alternate between scrolling and stopping by setting the inner marquee to travel in the opposite direction at the same speed as the outer marquee. Or do more levels with alternating speeds to make it zip around randomly. I think you had to set a max width for the inner marquees for this to work?
The blink tag was, of course, much hated back in the day, so as an experiment, I took the binary of whatever browser I was using (Netscape, I guess), searched for "blink", and changed it to "blonk". Tada, no more blinking!
I do this kind of thing with the Slack client (a silver lining of Electron apps: it’s dead simple) so that I can kill features I don’t like, such as hiding notifications or stopping the signal that I’m writing a message.
I find marquee extremely useful, for one reason: HTML injection.
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."
I browse Hacker News through a custom aggregator. This post is how I found out it’s susceptible to HTML injection - a (2020) was marqueeing across my screen.
A friend of mine would always put `<blink>` around his middle name as a quick and dirty way to test for missing escaping and possible xss. Back in the day this was surprisingly effective at uncovering problems :-)
"And the beast shall come forth surrounded by a roiling cloud of vengeance. The house of the unbelievers shall be razed and they shall be scorched to the earth. Their tags shall blink until the end of days."
> from The Book of Mozilla, 12:10 (about:mozilla)
And now Mozilla is being scorched to the earth. The End.
Same here, but this is in spite is the governance of the foundation looking so out of rails and simultaneously lake of better alternative I'm aware of with both better governance and fine enough technological state.
I assume you were being sarcastic? I see it the other way around - the sooner Mozilla gets off the drugs^WGoogle's money the better the chance we get a proper competitor to Chrome.
Um, so, how are Mozilla supposed to get the hundreds of millions of dollars a year it costs to pay engineers to maintain an evergreen browser without Google's funding?
How did they survive without their funding before they got it? And don't say that web standards are much more complex nowadays - yes, they are, because it is in Google's interest to make them such. Will it hurt? Yes. Will Firefox survive? I hope so. Is it a bad idea? No.
> How did they survive without their funding before they got it?
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.
The opposite will happen as they lose most of their funding. They will have to fire most developers and switch to chromium, to become yet another Chrome reskin. Congratulations, you killed Firefox.
Currently you can still reactivate the ad blocker extensions, it's a bit hidden behind a three dot menu and you have to confirm a scary warning but it's still possible to run u lock origin at the moment. They might disable the workaround later though.
The amusing thing is that even today, there's a "blink" method on JavaScript strings. It's totally useless today, but it's still there for whatever reason. In fact, they don't even HTML escape the argument, so they were arguably terrible from the beginning.
Removing it will cause old code to throw an exception. By making it a no-op the code will remain working. There's tons of old unmaintained stuff on the web.
I was a Master Navigator of the Meat Mysterious[0].
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.
I've wondered whether the marquee idea could be behind the UFOs/ UAPs that appear to move extremely fast. Specifically, you line up a bunch of drones that can communicate with each other via directional (or just weak) radio or laser transmissions. Then when a drone on one end of the line receives a radar pulse from an aircraft (etc.), it sends back a stronger pulse than its reflection would be, and simultaneously signals the next drone in line. That drone sends off a radar pulse and signals the next drone in line, etc.
The effect, as viewed from the aircraft with the radar, would be a somewhat larger (or more reflective) target moving rapidly.
The line of drones would not need to be straight, in which case it could simulate a fast-moving object that suddenly turns.
I just applied for an evisa for India. It was horrendous. Pages wouldn’t continue without telling you what was wrong (too many or not enough commas in the address/phone field was one). When returning to the form the pre filled data had quotes in, which then wasn’t valid. Missing labels on fields. Then the hilarious “what countries in the last ten years, list all or get deported” combined with “you have too many countries”. They only allow 20.
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.
All of that is true.
However, to be fair, these are older sites. The newer ones are generally cleaner and usable[1]. Even the services provided is much more streamlined.
This was to prepare you for navigating once there. I still have flashbacks to the Delhi Airport. Every time I turned a corner there was someone there asking to see the name on my itinerary (a random sheet of paper I printed out hat I didn't think I'd actually need) with my passport and ticket. It happened so many times I almost missed my layover.
Ah yes, the <BLINK><MARQUEE><H1> to tell everyone the website made in notepad in 1997 was still under construction in bold, Comic Sans, and fuchsia on a yellow background. Don't forget the lots of NBSPs so that the message scrolls off for even a longer period of time and the reader has to wait for their computer to shift the message back into the viewport.
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]
Considering the marquee tag works in basically all browsers [1], has anyone here actually found a good, unironic use for it in today's world of crazy CSS animations?
I use a bunch of marquees to create an animated scene on my homepage[0]. Different speeds for a parallax effect and even some multi-axis marquees for rain effect.
It’s used all over the place on Indian government websites, old and new. Often by <marquee>, sometimes by JS, maybe sometimes by CSS.
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.
Music players, including car radios and portable CD and MiniDisc players, did that around 25 years ago. It's sort-of a standard UI pattern for variable-length text in a fixed-size display.
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).
The day I discovered that marquee tags have a direction attribute, using which you can make the text go up/down left/right and use multiple of these tags, is still etched in my memory.
in the German Mozilla docs there's was a warning: "this tag is one of the worst things you can do to your users, please don't use this" which they sadly removed.
They took away the <blink> tag from us, due to what can only be explained as the high costs to maintain such a complex feature in modern browsers, and late stage capitalism.
One reason people hate these elements is that they were overused.
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.
A coworker of mine unironically added a marquee tag to an internal tool we were working on. Not as a joke, he just googled how to add scrolling text and copy pasted it, without knowing the history behind it
It's really simple, moving text is hard to read. As an example, turn on the local news (bear with me, I work for a TV station). You'll notice the scrolling ticker is likely simplified to focus on one headline at a time, with more pauses in between.
As others have said: scrolling text is harder to read than non-scrolling text. Scrolling text is useful in the real world when space is limited. On the web, there is no space limit, so almost no reason for scrolling text.
https://web.archive.org/web/20201111125145/https://danq.me/2...
I was there, 3,000 years ago.
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/...
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.
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.
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.
Framesets were great.
>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.
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.
All content on the web should have a unique, linkable, URL. Frameset breaks that.
That doesn't stop today's dynamically updating pages that also break the back button.
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.
SPAs were a low point, but I've found consistent and linkable URLs has gotten better with developers recognizing the importance due to "SEO".
Also crawlers can now evaluate SPAs. Googles crawlers will run JavaScript on the page making the SPA SEO issue much less of an issue now.
Idk if that counts as a low point or a high point.
There se excretes to this, particularly if you value speedy vs delayed updates to your indexing
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.
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.
Oh man, the good old times when you could get a job just knowing a bit of HTML, CSS and JS. I so wish I could go back.
Now I am micromanaging a LLM that gets to do the fun parts. I have become the middle management I always hated.
I agree. Personally I think we'd be better off without social media sites or smart phones
Punch cards. We need to go back to punch cards.
Why would we want to do that? The data density is quite low.
> I still don't understand the issue with frames.
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.
I remember working for a client who needed to support IE6 (with all the insane bugs/quirks/limitations) and I’d despair every time the designers would hand over a Photoshop design with rounded corners. They also needed it to be responsive (at the time mostly just different desktop sizes). Would usually require cutting the corners out and positioning them in table cells. There’s a certain amount of dev resilience you build having to do stuff like that by hand!
We worked with an internal design team, but basically just one UX specialist who has zero comprehension of how HTML, CSS or and web related technologies worked. At one point we where meet with "I don't like that the site blinks!" ... What do you mean by "blinks", we built it, it doesn't blink. Turns out she didn't like that that switching pages would cause the browser to load the next page and in turn there would be an ever so brief moment where the browser would show a blank page while loading the next page. This was in the initial ASP.NET and Ajax days, to the end result was "wrap the whole damn thing in an update panel".
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.
At least table rows didn't unexpectedly wrap to a new line like float-based layouts.
Even though it was a long time ago I still have IE6/7 workarounds burned into my brain, most of them float related but also having a whole stylesheet for that damn browser... <!--[if lte IE 6]>:
https://code.google.com/archive/p/universal-ie6-css/
Or just telling the designers "we can't do rounded corners for this client" (the client likely didn't care at all).
For some reason I actually really loved doing this. I remembering feeling disappointed when css got border radius.
I remember meticulously using the photoshop slice tool
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 remember meticulously using the photoshop slice tool
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.
That is what Fireworks was great for: https://en.wikipedia.org/wiki/Adobe_Fireworks
>Who here remembers frames?
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.
Plenty of modems/routers still use frames in their management interfaces.
I explained the concept of frames to a developer born after the millennium, and their reaction was that it is a pure magic.
I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-Beams glitter in the dark near the Tannhäuser Gates. All those moments will be lost in time, like <blink> and <marquee>.
I made a webchat with frames; an infinitely-loading top part for the text, and the bottom an input box that received 204 to not reload when you sent a message. I guess that was the most elegant way to do it in the IE4+ days. The top part could also receive a small <script> that would reload the frame on the right, containing the user list. Fun times. Used it with a couple class mates around 2000 iirc.
I managed to get real-time chat (and other real-time colab) working on IE4+ using long polling, by continuously adding <script> tags from JavaScript. The server would delay answering until there were new messages available, or some timeout. This was even before xmlhttprequest. Who needs websocket? :-)
Sounds fancy! My solution back then was infinitely auto-updating a frame with a meta refresh tag. It would receive a new <script> block that would update the contents of other frames. This of course wouldn't give real-time functionality.
It's still a way (with a frame autorefresh) to make chats on Tor, since many users will have JS turned off
I was expecting you to tell me that all of these moments will be lost in time, like tears in the rain.
b800h, meet jameslk (see post a few lines above yours)
"I've seen things you people wouldn't believe..."
Been there, have done (most of) this. Never used Silverlight, but did use VRML, Java Applets, and Chromeffects.
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/
2. <BGSOUND>
I remember a website about Ski-Doo snowmobiles that my friend was obsessed about (both the website and snowmobiles) in 1998 or so. It was from Canada, and the bgsound was the website owner saying something in French.
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 remember cgi.pm and the magic of communicating two ways.
Oh, man, this takes me right back. Scary how time gets away from you.
I remember WML <card> tag, essentially SPA 20 years before SPA even became a term.
Don't know if it was intentional, but your ramble reminded me of the lyrics of Losing my edge by LCD Soundsystem. However, as someone who also experienced most of this stuff, it was a fun read either way :)
Spacer gifs, OMG, the memories! <table> should be enough for everyone.
What is the motion jpeg hack? I made my own streaming too before websocket... but I never heard of this.
I remember when display flex was still new, experimental, and not universally supported :)
Started in 1998 with front page.
Fancy! Not even Front Page Express first?
Don't remind me, Front Page Express' generated HTML was the stuff of nightmares.
Still better than Microsoft Word.
My personal website uses an image map for its main navigation menu. It still works just fine.
You're in good company, Paul Graham's site does as well.
https://paulgraham.com/index.html
3000 years ago, when Ancient Egyptians argued over how they should format Papyrus text.
I think this is a reference to a LotR meme. https://youtu.be/Q63_FxegFsQ?feature=shared
For those who prefer not to visit yt, the quote "I was there, Gandalf. I was there three thousand years ago" refers to Elrond talking about the time when Isildur took the One Ring from Sauron.
Ahh, good times. I ran a "college dorm floor" website off my computer for a while and included a 997-word marquee on it, just rambling and talking about girls, depression, and philosophy. At the very end there was an exclamation point that was a href to a hidden page. Of course, someone hit view source to read the stupidly long message and found the page anyway.
I created this a while ago, and whenever I show someone they are shocked to see there is absolutely no JavaScript; all of the animations are done via marquee tags: https://udel.edu/~ianozi/
I probably haven't looked at the marquee tag in 20 years, so I could have just forgotten, but I was unaware it has a direction parameter to allow for vertical scrolling.
My favorite trick with <marquee> was to nest them, with different, alternating directions. You could make the contents alternate between scrolling and stopping by setting the inner marquee to travel in the opposite direction at the same speed as the outer marquee. Or do more levels with alternating speeds to make it zip around randomly. I think you had to set a max width for the inner marquees for this to work?
The blink tag was, of course, much hated back in the day, so as an experiment, I took the binary of whatever browser I was using (Netscape, I guess), searched for "blink", and changed it to "blonk". Tada, no more blinking!
I do this kind of thing with the Slack client (a silver lining of Electron apps: it’s dead simple) so that I can kill features I don’t like, such as hiding notifications or stopping the signal that I’m writing a message.
Yeah, but if someone had used <blonk> you would get... blonking I guess? :) Nice hack!
Exactly, haha! :) Thanks!
I find marquee extremely useful, for one reason: HTML injection.
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."
I browse Hacker News through a custom aggregator. This post is how I found out it’s susceptible to HTML injection - a (2020) was marqueeing across my screen.
When doing HTML sanitization, I always whitelist marquee as an easter egg (and almost nothing else)
A friend of mine would always put `<blink>` around his middle name as a quick and dirty way to test for missing escaping and possible xss. Back in the day this was surprisingly effective at uncovering problems :-)
"And the beast shall come forth surrounded by a roiling cloud of vengeance. The house of the unbelievers shall be razed and they shall be scorched to the earth. Their tags shall blink until the end of days."
> from The Book of Mozilla, 12:10 (about:mozilla)
And now Mozilla is being scorched to the earth. The End.
I don't know, I still use Firefox as my primary browser.
Same here, but this is in spite is the governance of the foundation looking so out of rails and simultaneously lake of better alternative I'm aware of with both better governance and fine enough technological state.
Root for the illegal Google monopoly then, because that's what Mozilla says they need to survive. (It's over soon.)
I assume you were being sarcastic? I see it the other way around - the sooner Mozilla gets off the drugs^WGoogle's money the better the chance we get a proper competitor to Chrome.
Um, so, how are Mozilla supposed to get the hundreds of millions of dollars a year it costs to pay engineers to maintain an evergreen browser without Google's funding?
How did they survive without their funding before they got it? And don't say that web standards are much more complex nowadays - yes, they are, because it is in Google's interest to make them such. Will it hurt? Yes. Will Firefox survive? I hope so. Is it a bad idea? No.
> How did they survive without their funding before they got it?
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.
The opposite will happen as they lose most of their funding. They will have to fire most developers and switch to chromium, to become yet another Chrome reskin. Congratulations, you killed Firefox.
I don't know how people can use anything else, especially now that Chrome doesn't support ad blockers.
Currently you can still reactivate the ad blocker extensions, it's a bit hidden behind a three dot menu and you have to confirm a scary warning but it's still possible to run u lock origin at the moment. They might disable the workaround later though.
It still supports stripped down as blockers. For the casual user something like ublock lite is probably perfectly fine
if you switch between chrome and FF (say work/home) the difference are glarring though...
This comment is under construction - check back here often to see updates!
Where are your visit counter and guestbook?
Right under the web ring.
For which browser is this page optimized?
Don't forget the [NEW]
The amusing thing is that even today, there's a "blink" method on JavaScript strings. It's totally useless today, but it's still there for whatever reason. In fact, they don't even HTML escape the argument, so they were arguably terrible from the beginning.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Removing it will cause old code to throw an exception. By making it a no-op the code will remain working. There's tons of old unmaintained stuff on the web.
I was a Master Navigator of the Meat Mysterious[0].
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…
[0] https://en.m.wikipedia.org/wiki/Mystery_meat_navigation
I really need to repurpose 90s.dev asap.
And not just to be another neocities.
There's so much lost joy and wonder to recover.
“Username checks out” - Reddit
Sincerely, just do what you love with it, don’t market it.
I've wondered whether the marquee idea could be behind the UFOs/ UAPs that appear to move extremely fast. Specifically, you line up a bunch of drones that can communicate with each other via directional (or just weak) radio or laser transmissions. Then when a drone on one end of the line receives a radar pulse from an aircraft (etc.), it sends back a stronger pulse than its reflection would be, and simultaneously signals the next drone in line. That drone sends off a radar pulse and signals the next drone in line, etc. The effect, as viewed from the aircraft with the radar, would be a somewhat larger (or more reflective) target moving rapidly. The line of drones would not need to be straight, in which case it could simulate a fast-moving object that suddenly turns.
I know it’s horrible design but I love using <marquee> to test things in HTML sometimes.
Lot of older India gov sites still seem to use these tags.
https://www.epfindia.gov.in/site_en/index.php
I just applied for an evisa for India. It was horrendous. Pages wouldn’t continue without telling you what was wrong (too many or not enough commas in the address/phone field was one). When returning to the form the pre filled data had quotes in, which then wasn’t valid. Missing labels on fields. Then the hilarious “what countries in the last ten years, list all or get deported” combined with “you have too many countries”. They only allow 20.
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.
All of that is true. However, to be fair, these are older sites. The newer ones are generally cleaner and usable[1]. Even the services provided is much more streamlined.
https://web.umang.gov.in/landing/
This was to prepare you for navigating once there. I still have flashbacks to the Delhi Airport. Every time I turned a corner there was someone there asking to see the name on my itinerary (a random sheet of paper I printed out hat I didn't think I'd actually need) with my passport and ticket. It happened so many times I almost missed my layover.
Holy crap, that's a website alright
Do you remember when there was a brief bug in Netscape that enabled multiple <title> tags to effectively animate the window title? That was a fun one.
In a similar vein, the little animated messages in the status bar was peak internet.
Ah yes, the <BLINK><MARQUEE><H1> to tell everyone the website made in notepad in 1997 was still under construction in bold, Comic Sans, and fuchsia on a yellow background. Don't forget the lots of NBSPs so that the message scrolls off for even a longer period of time and the reader has to wait for their computer to shift the message back into the viewport.
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]
0. https://en.wikipedia.org/wiki/Screen_tearing
Image of a construction worker digging
Yes. And it should be animated as the background image so you can't read any of the normal text in 6 px font without highlighting it.
also Guestbooks and the email icon of the word 'email' rotating around a globe.
You can put a marquee inside a marquee and make the DVD bouncing logo.
Did that on my first day of college, inside an .hta file for windows and blew my classmates minds. #hackerman
Controversial take: marquee is still useful, and I still use it!
Considering the marquee tag works in basically all browsers [1], has anyone here actually found a good, unironic use for it in today's world of crazy CSS animations?
[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
The correct use is alongside the “man with a spade”.jpg to let people know your page is under construction.
"Hey! Stickly Man! WHAAAAAAAAAAAT are you doing!"
https://homestarrunner.com/toons/under-construction
I use it to display RSS feeds on my personal website (https://maxbo.me) as a allusion to news tickers (which are themselves an allusion to ticker tape machines: https://en.wikipedia.org/wiki/Ticker_tape)
I use a bunch of marquees to create an animated scene on my homepage[0]. Different speeds for a parallax effect and even some multi-axis marquees for rain effect.
[0]: https://bradlyfeeley.com/ (no idea which browsers it renders properly in)
Trees and clouds! (Pixel + Chrome)
It’s used all over the place on Indian government websites, old and new. Often by <marquee>, sometimes by JS, maybe sometimes by CSS.
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.
Plex does something very similar to marquee to display an actors name when it's too long to fit under their profile pic. Seems like a good use.
Music players, including car radios and portable CD and MiniDisc players, did that around 25 years ago. It's sort-of a standard UI pattern for variable-length text in a fixed-size display.
Yeah, to really emphasize an important message.
Perhaps better semantics?
This was a perfect piece of nostalgia. I love that blink was created as a joke.
Interestingly, the default <marquee> doesn’t appear as smooth as a CSS animation would be?
Playing with the scroll speed makes it feel smoother:
In Chromium it's quite literally a CSS animation: https://source.chromium.org/chromium/chromium/src/+/main:thi...
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).
They weren’t smooth back then by default either.
I’m pretty sure that originally it was to reduce CPU load, and later was left that way for backwards compatibility.
The day I discovered that marquee tags have a direction attribute, using which you can make the text go up/down left/right and use multiple of these tags, is still etched in my memory.
The good old days of writing html on the windows 98 notepad.
No 20mb js framework, no ide, no ai "assistants", just pure, healthy, free range basement grown webpages the way god intended.
in the German Mozilla docs there's was a warning: "this tag is one of the worst things you can do to your users, please don't use this" which they sadly removed.
here is the German version: https://x.com/K0IN1/status/1025459517499367425
needs <xmp>, no pre is not a replacement.
without the marquee tag how were we supposed to build the scrolling LCD screens that dominated our physical electronics?
They took away the <blink> tag from us, due to what can only be explained as the high costs to maintain such a complex feature in modern browsers, and late stage capitalism.
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
One reason people hate these elements is that they were overused.
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.
A coworker of mine unironically added a marquee tag to an internal tool we were working on. Not as a joke, he just googled how to add scrolling text and copy pasted it, without knowing the history behind it
Never got the hate to these.
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.
People generally hate things that try to steal their attention away from the thing they are trying to focus on.
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.
It's really simple, moving text is hard to read. As an example, turn on the local news (bear with me, I work for a TV station). You'll notice the scrolling ticker is likely simplified to focus on one headline at a time, with more pauses in between.
So, it's bad on web but good on TV?
As others have said: scrolling text is harder to read than non-scrolling text. Scrolling text is useful in the real world when space is limited. On the web, there is no space limit, so almost no reason for scrolling text.
???
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?
HN hug of death?
https://web.archive.org/web/20250608044216/https://danq.me/2...