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.
> 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.
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 remember meticulously perfecting every trick that the slice tool eventually automated before it existed using Jasc Paintshop Pro: squeezing every kb for maximal presentation from pieces of a larger image into gifs or jpgs so that the parts of it which needed to animate or be interactive could do so and the large parts that didn't could remain as high quality as possible.
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 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.
A webchat that I used to go to back in the day implemented this too. I used to spend a lot of time there - it was my Internet home for several years. I miss it terribly.
I wish I could upvote this comment twice. Thank you for the walk down memory lane.
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 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'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>.
Memories. Made my first website in 1998. In Notepad. I had fun with HTML but not many ideas about what I could create. So I learnt HTML by making, in HTML, an HTML tutorial website. I was 12.
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.
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?
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.
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!
Binary editing was/is good fun. I remember replacing "__gnu_warning" with "__gnu_whining" to quiet some dumb nannying around gets(). Yeah, sure, buffer overruns, but if I'm writing some throwaway program, I can just not overrun the buffer.
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.
"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.
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.
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.
Informative. AOL also sued Microsoft for iirc $1 billion for their illegal Netscape shenanigans. That kept Mozilla going for several years when they really didn't have a product, and probably would have been shut down otherwise.
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.
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 :-)
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.
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.
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 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.
It's simple, really. You're not allowed into India if you've been to more than 20 countries in the last ten years. What are you trying to hide with all that globetrotting?
Man, I'm glad that in general form inputs have gotten a lot better. I was reading The Design Of Everyday Things the other day, and it was mentioning how most websites required an exact formatting and didn't provide an explanation...
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'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.
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
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.
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.
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.
They can be useful in a tabbed interface. Since the width of a tab is limited, and may not be large enough to fit in the text, scrolling the text in the active tab title may be better than hovering to show a tooltip (Though we should use the tooltip for the inactive tabs).
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).
Back in the ISP days of the 90s, if you used the Microsoft Internet Explorer Administration Kit (IEAK) and wanted to distribute customized versions of IE to your customers, one of the requirements was to use IE-only elements on your main website to promote usage of IE. Marquee was one of the least obnoxious ways to do that compared to other options.
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.
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.
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.
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.
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.
> 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.
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. 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.
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.
[dead]
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.
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.
> 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.
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.
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.
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 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.
Hm, have you been on the web lately? I've got bad news for you.
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/
I’m only 20 but when I immediately recognized this I felt so old.
I remember using the "Sliding Doors" technique.
https://www.htmlgoodies.com/css/how-to-create-sliding-doors-...
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.
I remember meticulously perfecting every trick that the slice tool eventually automated before it existed using Jasc Paintshop Pro: squeezing every kb for maximal presentation from pieces of a larger image into gifs or jpgs so that the parts of it which needed to animate or be interactive could do so and the large parts that didn't could remain as high quality as possible.
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.
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 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.
Fun, until you had dial up so slow the refresh happened again before anything on the page fully loaded (mostly an issue with images)
A webchat that I used to go to back in the day implemented this too. I used to spend a lot of time there - it was my Internet home for several years. I miss it terribly.
It's still a way (with a frame autorefresh) to make chats on Tor, since many users will have JS turned off
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 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..."
I wish I could upvote this comment twice. Thank you for the walk down memory lane.
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.
> Who here remembers frames?
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.
https://html.com/frames/
> I remember building site navigations in Java, Flash, and Silverlight.
Don't forget ActiveX (actually, yes, we should all try to forget)
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/
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>.
Memories. Made my first website in 1998. In Notepad. I had fun with HTML but not many ideas about what I could create. So I learnt HTML by making, in HTML, an HTML tutorial website. I was 12.
I remember building fluid views with rounded corners before border-radius.
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. :)
> Who here remembers frames?
Don't worry, they are still alive, the swedish crime statistics website still uses them [0]. It's a great experience for everyone.
[0]: https://statistik.bra.se/solwebb/action/index
I remember cgi.pm and the magic of communicating two ways.
> spacer gifs
Hacker News actually still uses these for comment indentation, check this page’s source code.
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
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.
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 :)
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.
I remember when display flex was still new, experimental, and not universally supported :)
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.
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.
https://no-js.abhij.it/
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?
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."
When doing HTML sanitization, I always whitelist marquee as an easter egg (and almost nothing else)
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.
Same here. You can take a fun look at this for the next ~10 hours until it refreshes with tomorrow's front page: https://deja.de.hueve.ar/hn
Also: I built the thing, so maybe I should fix it some time.
This whole comment section must be absolutely hell to look at on that...
Ironically, it's a titles/links only aggregator. My way of browsing social media antisocially.
I've always used the <plaintext> tag - an unclosable element that converts the rest of the document into raw HTML. It's very obvious.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
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!
Binary editing was/is good fun. I remember replacing "__gnu_warning" with "__gnu_whining" to quiet some dumb nannying around gets(). Yeah, sure, buffer overruns, but if I'm writing some throwaway program, I can just not overrun the buffer.
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!
"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.
Seamonkey is still out there. The rot hasn't touched the Seamonkey foundation, in part because only like, my dad uses, or has heard of, Seamonkey.
Seamonkey is pretty much the descendant of the OG Netscape Communicator codebase. So it's kind of on topic for retro Web stuff.
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.
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.
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.
Informative. AOL also sued Microsoft for iirc $1 billion for their illegal Netscape shenanigans. That kept Mozilla going for several years when they really didn't have a product, and probably would have been shut down otherwise.
I don't know how people can use anything else, especially now that Chrome doesn't support ad blockers.
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...
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.
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 :-)
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]
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.
Remember clicking on various places to uncover Easter eggs in Homestar Runner?
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.
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.
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
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.
It's simple, really. You're not allowed into India if you've been to more than 20 countries in the last ten years. What are you trying to hide with all that globetrotting?
Man, I'm glad that in general form inputs have gotten a lot better. I was reading The Design Of Everyday Things the other day, and it was mentioning how most websites required an exact formatting and didn't provide an explanation...
Holy crap, that's a website alright
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 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 know it’s horrible design but I love using <marquee> to test things in HTML sometimes.
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.
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.
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
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.
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/...
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)
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 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)
I love the use of emoji in that animated scene! I would never have guessed; I only found out from looking at the raw HTML.
Trees and clouds! (Pixel + Chrome)
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.
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.
They can be useful in a tabbed interface. Since the width of a tab is limited, and may not be large enough to fit in the text, scrolling the text in the active tab title may be better than hovering to show a tooltip (Though we should use the tooltip for the inactive tabs).
Yeah, to really emphasize an important message.
Perhaps better semantics?
Android also supports a `<blink>` tag in layout XML. It's not documented well, but it's still in the latest source: https://android.googlesource.com/platform/frameworks/base/+/...
Interestingly, the default <marquee> doesn’t appear as smooth as a CSS animation would be?
Playing with the scroll speed makes it feel smoother:
They weren’t smooth back then by default either.
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).
I’m pretty sure that originally it was to reduce CPU load, and later was left that way for backwards compatibility.
This was a perfect piece of nostalgia. I love that blink was created as a joke.
Back in the ISP days of the 90s, if you used the Microsoft Internet Explorer Administration Kit (IEAK) and wanted to distribute customized versions of IE to your customers, one of the requirements was to use IE-only elements on your main website to promote usage of IE. Marquee was one of the least obnoxious ways to do that compared to other options.
https://oopsallmarquees.com/
needs <xmp>, no pre is not a replacement.
90s web:
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.
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.
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
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?
The opposite. It's been phased out of TV, (more pauses, less scrolling text) around the same timeframe that it phased out on the web. I threw together a visual comparison: https://gifrun.azureedge.net/video/4e99ff8b27414bbb93c3cc297...
Wow. Great comparison, thanks!
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?
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
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
Controversial take: marquee is still useful, and I still use it!
Nowadays you just reimplement them in CSS.
without the marquee tag how were we supposed to build the scrolling LCD screens that dominated our physical electronics?
I think <marquee> is even worse than <blink> (even if you do not use CSS).
Something else I have to explain to Gen Z existed at one time.
HN hug of death?
https://web.archive.org/web/20250608044216/https://danq.me/2...