On the other side we were told that those colorful gradients that will be the fad of the 20s are cheap and we were scolded by professional designers for using them.
Not that we had CSS gradients, we were using gifs or jpegs.
We’d generate a 18x1 GIF with a gradient color change (or from a solid color to a transparent color) and stretched that out over however pixels we wanted to create a gradient-like effect. e.g
Yeah, I think there's some deliberate mistakes in there for understated comic effect - e.g. "To this day [1x1.gif] is the only way to vertically center elements."
The joke (at least the DHTML one) is probably that only people who were developers then will know that's wrong. (Or I suppose this could have been written by someone who wasn't around at that time and this is a bit of faux nostalgia!)
I think the joke about it being "the only way to vertically center elements" is just referring to the fact that it's still kind of hard to do vertical centering and there's still no definitive, easy solution after 27 years of CSS. (It's now doable with Flexbox or CSS Grid as well as more obscure hacks, but it's still more fiddly than it should be.) Could be wrong, though.
Edit: I think thejohnconway has the answer [1]: the post was written before the Flexbox stuff for vertical centering was widely supported.
There were still less nasty options than 1x1 GIFs available, like "display: table-cell", so it's still very likely a joke.
It's almost certainly a joke but not obvious exactly what the joke is. What it actually stood for (in case you don't know) is "Dynamic HTML." My guess is that he's drawing a parallel with "distributed" as a modern day buzzword that's used in so many ways it's almost meaningless, but attracts attention and money almost automatically (other modern-day buzzwords like this include "blockchain," although that's fading, and "AI").
Incidentally, nowadays we never refer to DHTML because probably over 99.9% of pages use at least some JavaScript and CSS, so it's redundant to even mention them; you just say "front-end development."
I remember it taking a few years between DHTML becoming a buzzword and XHR becoming popular. XHR was slept on for a while even though it was available in all major browsers by the early 2000's. Back when we were calling things "DHTML," updates originating from the server typically would happen by refreshing the whole page, or sometimes an IFRAME if you wanted to get fancy [1]. Once XHR finally started to get popular is when people started talking about "Web 2.0" in the mid 2000s.
I heard that someone did a talk on why it took so long for the Web 2.0 phenomenon to happen even though the technologies were available for several years before. Can't remember who.
A little known fact is that even streaming updates (e.g. for live chat) were actually not that hard to implement on the front end going back to the original days of XHR, via "long polling" (basically starting a new XHR request that you held open until the next piece of info comes in) though it took until well into the Web 2.0 era for that to be common. The problem was actually on the server side; to cope with long polling, the server would have to keep a long-running thread (and in the case of CGI, a whole process!) for each of those open requests and the servers would get overloaded. Nowadays of course servers have much better hardware, and we have technologies like nginx that can handle huge amounts of connections in one thread.
In principle you could build almost everything in the modern day front page of Facebook or Google results page with the tools we had in 2001, front-end wise, but the servers couldn't handle long polling for the streaming updated needed for things like the Facebook chat. Also the pages are so complex that it would be easy to get yourself tied in knots without modern conveniences like CSS frameworks (or even resets!)
DHTML was long before XHR; the term was more or less already out of fashion by the time XHR came along.
DHTML was used for situations like when you had hierarchical selects where the contents of the second select depended upon what you picked for the first select. All the code and data was delivered up front with the page load; you didn’t go back to the server for it with XHR.
That's right, I think I let the concepts overlap in my head a bit. Back then I was mostly doing game dev for PCs and some backend work. I remember pre-web 2.0 (loading a whole new page just to see the next tile over on MapQuest or Yahoo!Maps was.. annoying) but my just-waking mind probably confused dynamic to also mean dynamically-loaded. I shouldn't jump on HN before getting out of bed. I would delete my GP comment if I could.
The ability to pull down new results and load them was largely enabled by DHTML, though, because you still need a way to update the page with the new data. But now that I'm more awake I agree DHTML and the unrelated web2.0 features are different things.
> It's almost certainly a joke but not obvious exactly what the joke is.
That's the conclusion I've come to from all the responses. (Thanks everyone.)
The reason I asked is because I remember web development in the 90's, and the article while irreverent in tone misses the mark for me.
I think it's aiming for "The Register" style irreverence but their style is to have a cynical mocking and sarcastic tone while still being factually accurate, while this article changes facts in a way that feels like a joke, but stops short of actually making the joke or point it wants to make.
It's as if "This joke is left as an Exercise to the reader". Given the range of different explanations of "the joke" that have followed, I've come to the conclusion that the author has nailed the tone of being funny while not actually being funny.
The whole page is tongue-in-cheek. In the '90s, <blink> was only supported by Netscape while <marquee> was only supported by Internet Explorer, so combining the two didn't make a lot of sense. Mozilla only added <marquee> support in 2002: https://bugzilla.mozilla.org/show_bug.cgi?id=156979.
I guess the joke here is that you used to do really a lot of in-line JavaScript in HTML, there was even a time during high latency where it was better to use inline JavaScript than JavaScript imports (<script src>) for faster rendering times (you usually just had 2 concurrent connections with high latency and low bandwidth). So “distributing” your JavaScript in a single HTML all over the place was the way and fail to go :-)
> DHTML, which absolutely stands for “distributed HTML” because that’s the name and this isn’t obvious bait for the no fun crowd at Hacker News…
I’m confused by this discussion…was the above quoted bit added later or something? Because as it stands, it seems pretty clear that making this very discussion happen is the punchline.
I still use tables for layout, partially. In order to make it responsive, I combine multiple tables with inline-block to allow the tables to reflow on the page.
There are more "modern" ways of doing this, but I haven't found any that are also compatible with my goals of maintaining backwards compatibility.
My first paying client when I was 19 (so around 1998?) commissioned a local high school graphic design student to hand paint this crazy village scene with stores. She then had it professionally scanned and gave me the files... which I then used to create an image map for each of her little "store fronts". She couldn't accept payments online (they didn't teach me that in my community college HTML course), still had to print out an order form and send in a check. I will never forget the horrid repeated plaid background she made me use.
My favorite workflow was to make a totally l33t render with 3dsmax, put it in Photoshop to draw UI buttons, and then use Imageready to slice it and autogenerate the html slices and maps. Instant fancy website that made me a cool kid as far as I was concerned
If you were using 3DS for web design you were legit l33t :)
I pulled an all-nighter to hand in a college homework to demonstrate gradient descent using Maya once. Sadly, the teacher was not impressed. Good times.
> To this day it is the only way to vertically center elements.
Not true anymore (edit: didn't see the 2014) but the productivity cost of not being able to just "vertical-align: middle;" inside divs for the last 30 years must be billions of dollars.
Also does anyone remember the fade of the overline style on :hover links? It must has been around the IE4 or IE6 era.
Tables were also used to make divs and buttons with rounded corners, but that was true into the 2000s as well. The agony of designing and splicing them in Photoshop and putting them in table cells...
Nowadays I just ask ChatGPT to write the CSS for me for that, and amusingly, it seems to be able to produce at least a dozen of solutions (often came with redundant rules, too: like having 5+ rules when 2 or 3 of them are enough).
You joke, but I am pretty sure, that in some heads that idea is already spinning. When can they hire fewer people and make those fewer people simply use ChatGPT or some other model. We might see an even further decline in web quality as a result, as we get even more copy&paste devs.
Increased productivity and doing certain tasks in less time or with less people has been going on forever and certainly last 30 years in web development. The growing businesses use the extra capacity to expand in other directions whether new products or new features. The stagnant companies continue to struggle with less.
Why do so many hackers have so much difficulty seeing that the current state of public LLMs is not the pinnacle of AI technology? Nobody ever even claimed that they were.
Meh, anyone who hasn’t been able to multiply their productivity with chatgpt is either is too stubborn to try it or, well, i’m not sure how you can mess this up.
From writing sql boilerplate to copy-pasting my entire pico8 game and going “add repulsion force to enemies so they don’t clump up on one tile” to using it to provide examples instead of synthesizing them from a manpage, it’s insanely good.
oh it helps, it doesn't multiply my productivity, I wish it did!
It marginally increases my productivity and reduces some friction, honestly I'm more than happy for it to write as much code as it can on my behalf, it just can't.
I suspect those for whom it is a big game changer, were likely engaged in lots of activity which is cookie cutter.
How much we were held back by backward compatibility before useful standards for things came ... But nowadays I just ignore non-standard styling. Just use the standard, because support is sufficient and browsers not supporting the standard sufficiently to make the website unusable are rare. By using the standard one also gives their developers a set target to get implemented.
iOS Safari has so many odd bugs in layout and CSS that trips up its touch based scrolling, it is so much like the IE days where other browsers worked and the site looked good, then you load in IE (Safari now) and something is broken.
I once (~10 years ago, wow the time flies) found and reported a bug in iOS Safari where when you enabled touch scrolling on an element inside <body>, it would scroll vertically when you swiped horizontally and vice versa. But only when the page also contained an invisible <iframe> that we happened to need because reasons (GWT stuff). Apple fixed it eventually, but I'd love to know exactly what the root cause of the bug was…
Ironic. But I was not really talking per-browser prefixes, those are newfangled 2010s stuff. I'm talking way back in the day, when different browsers (well, mostly IE) sometimes had completely different ways of achieving something, in some cases requiring ~~unthinkable hacks~~clever and elegant solutions to avoid interference.
OMG the nightmares. I still had to deal with legacy IE CSS until a few years ago. The obscure and endless vendor prefixs to fix something it was never intended for.
It's still a huge PITA and requires all sorts of subtle understandings. Even in tailwindcss it's not simple, you need to think about what kind of element is it (block or not), is it text or not, what layout is on the parent, yada yada yada.
Here's a puzzle I had from the olden days: how do you do webpages with header and footer such that the footer is always at least as far down as the window height, but if the content is less than enough to push the footer below the fold it should be centered.
I remember that being far harder than it needed to be. I was a child though so maybe I just didn't get CSS well enough.
Really wasnt a great experience... You could do similar with tables, everything was tables. But you had to keep your open and close in check across the page. Templating frameworks were less flexible earlier on. Sucked when say a large corporate team did headers and footers separate from your app team.
In modern CSS I'd try this: make a super element around the header and content, set the min-height of that to 100vh, and the display to flexbox, with flex-flow: column nowrap; and then align-items: center;
But watch out for 100vh on mobile. It doesn't account for the sometimes there, sometimes not there address bar.
To solve that, there's svh (small), lvh (large), and dvh (dynamic).
If you want to make a div stretch to the height of the window, so that something can appear exactly at the bottom before scrolling,
{
height: 100vh;
height: 100svh;
}
works best... the first line is there as a fallback for the few browsers that don't yet support svh... and if svh is supported it will replace the first line.
These modern days I'd personally skip over flexbox and use CSS Grid. I find grid-template-areas such a nicer to read map than trying to decipher complex nests of flexbox and I'm finding more every day that I prefer CSS Grid even in places that don't seem to be 2D layouts yet and could just be 1D flexbox.
> The agony of designing and splicing them in Photoshop and putting them in table cells...
Wasn't there a Photoshop-adjacent tool that did the slicing for you? I remember a print designer on my first job feeding what was, essentially, a full-bleed leaflet design through it, and producing a "landing page" with hundreds of table cells.
Photoshop itself did have a "slice tool" which allowed you to draw slices. There was a special export mode which exported all these slices for you, and IIRC, could even generate a tabletastic HTML for you. Maybe this is what you remember?
Adobe Imageready , was capable of visually making image-maps (you added links to sections of an image) and also had tools to create Gif animations (later embedded into Photoshop proper).
A page I have for one community project still uses those Imageready generated maps :)
> Tables were also used to make divs and buttons with rounded corners, but that was true into the 2000s as well. The agony of designing and splicing them in Photoshop and putting them in table cells...
Wasn't an image with a click <map> easier? I wasn't old enough to write very complicated html pages so my experience is lacking here.
I still remember learning to make the layout of a whole page as a table layout in school, with images in table cells for drawing nice borders around sections of the website. And we did that with GIMP!
You could make a fantastic looking website with use of imagemaps and judicious use of hover image replacement. Glowing buttons, drop shadows, you name it.
Depends. I'm the dialup days,. Cutting up an image and having it in a table could let you optimize each fragment as a gif with more limited pallet. So it would look better and be smaller. Especially with rollover image replacement.
I kind of wish that attention to detail for payload size was more common today.
From vague memory, images of buttons were indeed used, but tables or other tricks were necessary to dynamically adjust container size to its contents, e.g., for internationalization.
it's referring to using a 9-cell table to make an element where the corner sizes stay static, while the middle column and middle row stretch horizontally and vertically respectively to match the size of the central cell (which e.g. has variable length text)
then with background image tiling in the left/right and top/bottom middle cells you can get an effect like a drop-shadowed panel that sizes responsively
you'd probably set the flexible cells to width=100% and then have a 1-pixel gif in the edge cells to enforce the desired min-width
I was sad the article didn't mention anything about the 216-colour "web safe" palette, but perhaps the author wasn't old enough to remember having to support users with < 24-bit colour displays... or when 1024x768 took over from 640x480 as the min screen size, allowing use of fixed-width layouts >600 pixels (the max possible: 640, minus browser default page margin, minus scroll bar)...
Some websites did do this. But adding actual text that can be indexed by Ask Jeeves doesn't work with this solution.
Macromedia had this crazy system where you could slice your art up in Fireworks, and then ask it to generate the HTML and Javascript, then you could fine-tune it in Dreamweaver.
> > To this day it is the only way to vertically center elements.
> Not true anymore (edit: didn't see the 2014) but the productivity cost of not being able to just "vertical-align: middle;" inside divs for the last 30 years must be billions of dollars.
Even back then (possibly even back in the 90s? I know this existed in the 2000s) we had "VALIGN=MIDDLE" inside table cells.
Right, people seem to forget that table-based designs ruled the roost in the 90s and early 00s.
All of the vertical align, layering, etc hacks came from people not wanting to use tables anymore and divs (and other block elements) finally becoming more usable. Those hacks were the growing pains of an entire shift in paradigm.
Tables made much more intuitive sense than something like flexbox now but that came at the expense of being a nightmare to maintain.
Trying to hack a table layout together often led to frequent edits and initial attempts to maintain clean layout comments ended. You're left with never ending <tr><td><tr><td><tr><td> that you hopefully at least indented to maintain sanity. But god help you if your stumbled into another person's table layout code...
Spending time just entering "here", saving the file, and seeing where the "here" shows up. By the time 5pm rolled around "here" often turned into something like "ass" or "fuck", or if it's really bad "fuck you". IYKYK
I didn't say the transition was a bad one. I said that there was a decade or so of warts + growing pains as HTML and CSS grew to accommodate freeform block layouts. It wasn't until HTML5 + CSS3 that it was super usable, and until Flexbox that it became somewhat easy.
In some ways. There was at least a logical organization around a table, as long as you could wrap your head around all the markup and maintain it. Nested divs with CSS felt like you sometimes be halfway down a road that will never lead to where you want to go.
This week I ran into a problem with vertical centering I couldn't figure out: Text in a flex item with overflow ellipses and vertical centering. Other people online have shared solutions that did not work for me, but I've since convinced myself it looks better as-is. Billions of dollar is not an exaggeration.
Ah, the 90s - a time when <table> was the answer to every web layout question. Miss aligning your text? <table>. Need a fancy menu? <table>. Creating a full website? Nested <table>s! Who needed CSS when you had rows and cells to hack your way through design? Good old days of <td>-ing everything!
That's because Tables actually map to how digital imaging works: dividing an area into little squares and deciding what to show in it. The screen does it, the driver does it, the window manager does it, the desktop primitives do it... and then you get to the browser screen, and suddenly you have to figure out a byzantine system of self-mutating shapes.
I was an early CSS supporter but man, didn't the boffins screw up that one.
That’s nothing. The real state of the art was putting a smiley GIF inside a horizontal marquee, inside a vertical marquee, and setting behavior=“alternate” on both marquees.
For your pleasure, here’s how to do a marquee in pure CSS:
Or you put the main table inside a horizontal marquee, and the column that contains your side navigation inside another horizontal marquee that scrolls at twice the speed.
Then the navigation "rows" the entire site across the screen.
I don't remember if this was a common technique, but before XmlHttpRequest (came in 2000, i think) we used to do "Ajax" by loading data into an invisible iframe and reading the contents. Worked well iirc.
Also back then (up until ~2005) browsers were hilariously insecure. For example I was in a forum of a local youth club and you could have signatures that were displayed under every post so I added some edgy image linked from my own webserver.
Some day I accidentally put the whole folder on a password protection which prompted the "username password" login window on every page my signature was linked to. FOR ALL USERS.
I realized users would think that the forum software would ask them to log in again for some reason so I basically got all passwords of people in the forum in plaintext on my webserver.
I also don't know how widespread this technique was back then, but I'm shocked this was left out of the article. This phenomenon was literally the method that transformed a "websites" into "webapps" in the early days. We would use pools of invisible iframes to constantly update different parts of the page for a "reactive" experience. The author mentions various important hacks that define the early days, but missing this one seems like a blunder to me.
Wait, I still use dotted underlines and on my blog, and it does get praise for its design.
The dotted underlines look nice, but I guess the is just something I used to add to work around layout quirks in Internet Explorer except I never bothered figuring out in which places they're no longer needed...
Dotted underlines weren't supported by all browsers. Chrome rendered them as dashes... or was it the IE? Regardless, they weren't "portable" unless hacked using background-image on the offset.
I still use to put more than one space between 2 words in text. this requirement pops up surprisingly often. Too lazy to wrap them in spans and use paddings!
As far as I can remember, FrontPage was pretty nice. I built my first home page with it. I wanted to (visually) best all of my friends on IRC. So I designed how I wanted the page to look in (an obviously pirated copy of) PaintShop Pro. A sort of an embossed oval with navigation links on the perimeter, with all the page content appearing inside the magic oval.
But to wrangle such layout to HTML was not easy in the late 90s. I eventually managed to find out that other pages used <table> elements to force position stuff. FrontPage allowed me to stitch the individual images from PSP to a table in a WYSIWYG environment - I don't think teenager me would have had the patience nor understanding to ever do it without FrontPage. When I evenetually got it to render without glitches in IE I was _so_ proud.
The only complaint to my GUESTBOOK I got was from some guy using "lynx" (a CLI web browser) who said navigation was impossible. I only later learned about the "alt" attribute for non-visual users. Not sure if FrontPage would've even allowed me to set it though.
I have a rather large website to manage. Based on Tailwind. There are still some fucking and <br /><br /> tags around because the original dev used layout all those text containers over image containers and wasn't told there would one day be no text.
N+1 still loves those 1x1 transparent GIF for newsletters.
I remember how shocked my friends looked whenever they came by and saw it open on my screen. They never understood why I spend hours on that thing instead of just playing games.
The first time I thought about learning to code was when I visited Linkin Park's website. Sure, it took 10 long minutes to load but it was a masterpiece of its own.
I'd just open the website and stare at it. And one day I just decided that I'm going to make one myself. I'm trying still...
No, it was from around the launch of meteora iirc.
I tried to look it up, but the only copy that have a bearing resemblance to what I remember doesn't load very well as many files seem to be missing. And, the snapshots after that one just keep returning a 302 error :/
I remember using FrontPage quite a bit too. It had some... interesting quirks when it came to outputting HTML, but it seemed fine enough for me at the time.
Which also reminds me; did anyone actually use the FrontPage Server Extensions they had for it? I remember the tool having a bunch of dynamic features like counters and guestbooks that relied on them being installed, and web hosts sometimes having these extensions listed in their features, but I never saw any sites actually using them.
I also remember finding out about scripting with either VBScript or JScript (which was different from JavaScript).
Shortly after, I discovered that there's a function capable of listing folders and files from the visitor's hard drive. No permissions needed. The browser just had full access to the hard drive.
Naturally, I wrote a script and loaded it on the homepage of my website. The goal was to save, on a file, the contents of visitors hard drives' contents.
For some reason that never worked. But yeah, the internet back then was a very scary place.
It was just Microsoft's name for JavaScript because they didn't want to deal with Sun's trademark, but they did add a sprinkle of their own extra stuff in there without talking to any other implementers about it. That was par for the course for Microsoft of the day though.
I used FrontPage to teach myself how to create websites (if you could call it that). I placed elements in the WYSIWYG editor and then looked at the code which elements etc were produced. Such an amazing time.
Frontpage was notoriously horrible. It'd make pages that usually looked the way people wanted them to, but the source was a total mess. It was full of redundant and unnecessary tags. You could spend ages cleaning up HTML written in frontpage but if you put in the work you could decrease pageload times and file sizes significantly. Personally, I avoided it at all costs and stuck to text editors. Frontpage was so terrible that it made me resist using Dreamweaver at first out of fear that it'd be just as bad.
It's unmarked sarcasm. I don't think it's become easier or simpler in all seriousness. This isn't a bad thing- as things become more important, more concerns rise above the surface, and as more concerns rise above the surface, dealing with them all makes it harder.
The PHP code generation it did was hilarious - I remember my designer partner trying to make a dynamic form, and it ended up with 1400 lines of code where 14 would have done.
Ah yes, transparent images to get equal-width spacing on terrible browser engines like Opera and IE. Tracking pixels. Mixed HTTP and HTTPS content warnings. Java Applets. Perl scripts. cgi-bin. Uploading files one-by-one through a web portal (not even FTP). Building entire sites out of a mosaic of images. Having multiple versions of your site for 800x600, 1024x768, etc.
Yeah you try SFTP on Windows FTP thingy then Filezilla too and it obviously fails on both. Plain FTP works but you feel paranoid so upload the zip file of your site via the slow web interface and unzip it on the server.
If you yearn for “the good old days,” consider that we’re living through “the good old days” of AI. In 30 years a blog post like this will poke fun at prompts, chatGPT, chat-with-docs apps, dealing with hallucinations, and what else?
Having to bribe AI with $200 tips. Giving them pep talks to convince them they are capable of doing something. Trying to persuade them not to be so gullible they’ll do anything untrusted data asks them to. Telling them you have no hands so that they’ll write code for you. Flattering them by telling them they are an expert in something.
Don't forget that tables could be used for rounded corners. Or maybe I'm an early 00s web developer with that? The trick is that we created 3×3 tables, and aside of the middle cell, it would contain <img>s, so that the creation was a website element with rounded edges, the pinnacle of human expressiveness.
Since HTML emails were also the rage, and email clients updated much slower than browsers, this technique was used well into the 2010s, if you wanted your thing to be displayed correctly.
Will never forget having to create collections of tl.gif, tr.gif, bl.gif etc. images for those 3x3 tables, not to mention the 1x1.gif the article mentioned that was needed for the left/right cell backgrounds to show since browsers at the time didn't render background images of empty cells. Good times.
They're back now. Hard corners were kind of a big thing in the early 2010s, think Android Holo, Windows 8, etc.
I think Apple popularized the return of rounded corners in software with the iPhone X launch, when rounding the corners of smartphone screens became popular.
macOS rounded the window corners more, I think with Big Sur. And Microsoft followed suit in Windows 11.
I think several things in this article were more from the early 00's than the 90's.
Before using tables for rounded corners, I remember playing with a multi-chat app called Trillian (which handled yahoo chat as well as ICQ and others). It could be skinned to your liking in much the same way you were dealing with rounded corners. The top and side cells were repeating images so resizing the window would work well.
Let's not forget frames, the original 'solution' to the problem of having to edit the navigation bar on every page.
Unfortunately, you then had to figure out what to do if someone accessed the frame page directly, since search engines could still index these parts of the page seperately. And they always felt jarring and awkward too, since the cutoff between sections was always obvious...
If you are being framed by other websites, you deploy your 'frame-buster' script. If your page is orphaned without your own frames, then you summon your 'frame-joiner' script.
Well, actually, there was only a short time, when more than one had been widely used.
Something like Mosaic - Netscape - IE - Mozilla/Firefox/The Browser Now Known As Vivaldi/... - Chrome
I seem to remember Netscape and IE having had similar market shares for a while at that time (the infamous first browser war), but my memories might be distorted to be honest.
If I had to hazard a guess, it'd be that HTML email is probably one of the lowest priority things on the roadmap over at Google or Microsoft. The vast majority of regular folks sending emails send mostly plain text, and even many company sent emails also on the basic side (though with these limitations, it's probably self reinforcing there).
Add this how more complex emails could potentially lead to security issues for their webmail clients and waht not...
And well, "eh, good enough" is probably the order of the day.
In fact, I used them too around 2001 or so for my website when I did not enough programming/scripting to add a common layout to all content pages. That's how I originally implemented a two column layout: a narrow frame on the left for navigation links and a wide one on the right for content. I don't do it anymore, of course. I do know how to program now and generate my HTML website using a tiny Common Lisp program that adds common headers and footers to all my web pages.
We've come so far. Using a language from the 60s to write markup in a language from the 90s all so we can feel good by avoiding writing imperative code in another language from the 90s.
Seriously though, why can HTML not have a client side include?
The real pros used server side includes, where you could drop specially formed comments into your HTML which then be processed by Apache and replaced with the content of another file before being sent on to the client.
Likewise, I think its under appreciated just how many people got their start in this industry through tinkering with things because they seemed interesting.
i got my start with a copy of Gorillas - a QBasic game - when i was maybe 7 or 8. to play it you had to open the code and execute it. one day i got curious what all of the gibberish text meant, and that was the start of my journey: a damn game of gorillas throwing bananas! now here i am.. 30+ years later and eternally grateful for those pixelated primates. i sometimes wonder what drove me to tinker with that code that day.
A comically large proportion of “AJAX”-type use of JavaScript could just be frames and probably perform better, if frames had evolved a bit rather than remaining stagnant.
Fix that and give us HTML tables with basic features built-in and datasource-backed tables + list views back in the mid ‘00s and mind-boggling amounts of time and money could have been saved.
Instead, none of that happened, and it still hasn’t.
Don’t even get me started on how much money could have been saved if the Web had adopted payment standards so that the browser itself could handle payment input.
405 comments
[ 4.1 ms ] story [ 324 ms ] threadNot that we had CSS gradients, we were using gifs or jpegs.
<IMG SRC=“/gradient.gif” HEIGHT=“18” WIDTH=“600”>
Is this a joke I don't understand?
The joke (at least the DHTML one) is probably that only people who were developers then will know that's wrong. (Or I suppose this could have been written by someone who wasn't around at that time and this is a bit of faux nostalgia!)
Edit: I think thejohnconway has the answer [1]: the post was written before the Flexbox stuff for vertical centering was widely supported.
There were still less nasty options than 1x1 GIFs available, like "display: table-cell", so it's still very likely a joke.
[1] https://news.ycombinator.com/item?id=39127936
Incidentally, nowadays we never refer to DHTML because probably over 99.9% of pages use at least some JavaScript and CSS, so it's redundant to even mention them; you just say "front-end development."
This was around when XHR first debuted and devs could stop relying on hacks or Flash to do it.
I heard that someone did a talk on why it took so long for the Web 2.0 phenomenon to happen even though the technologies were available for several years before. Can't remember who.
A little known fact is that even streaming updates (e.g. for live chat) were actually not that hard to implement on the front end going back to the original days of XHR, via "long polling" (basically starting a new XHR request that you held open until the next piece of info comes in) though it took until well into the Web 2.0 era for that to be common. The problem was actually on the server side; to cope with long polling, the server would have to keep a long-running thread (and in the case of CGI, a whole process!) for each of those open requests and the servers would get overloaded. Nowadays of course servers have much better hardware, and we have technologies like nginx that can handle huge amounts of connections in one thread.
In principle you could build almost everything in the modern day front page of Facebook or Google results page with the tools we had in 2001, front-end wise, but the servers couldn't handle long polling for the streaming updated needed for things like the Facebook chat. Also the pages are so complex that it would be easy to get yourself tied in knots without modern conveniences like CSS frameworks (or even resets!)
[1] https://en.wikipedia.org/wiki/Dynamic_HTML
DHTML was used for situations like when you had hierarchical selects where the contents of the second select depended upon what you picked for the first select. All the code and data was delivered up front with the page load; you didn’t go back to the server for it with XHR.
The ability to pull down new results and load them was largely enabled by DHTML, though, because you still need a way to update the page with the new data. But now that I'm more awake I agree DHTML and the unrelated web2.0 features are different things.
That's the conclusion I've come to from all the responses. (Thanks everyone.)
The reason I asked is because I remember web development in the 90's, and the article while irreverent in tone misses the mark for me.
I think it's aiming for "The Register" style irreverence but their style is to have a cynical mocking and sarcastic tone while still being factually accurate, while this article changes facts in a way that feels like a joke, but stops short of actually making the joke or point it wants to make.
It's as if "This joke is left as an Exercise to the reader". Given the range of different explanations of "the joke" that have followed, I've come to the conclusion that the author has nailed the tone of being funny while not actually being funny.
I’m confused by this discussion…was the above quoted bit added later or something? Because as it stands, it seems pretty clear that making this very discussion happen is the punchline.
There are more "modern" ways of doing this, but I haven't found any that are also compatible with my goals of maintaining backwards compatibility.
https://www.creativebloq.com/adobe/image-slicing-photoshop-6...
(2014)
I miss the early ugly web lol.
I pulled an all-nighter to hand in a college homework to demonstrate gradient descent using Maya once. Sadly, the teacher was not impressed. Good times.
Not true anymore (edit: didn't see the 2014) but the productivity cost of not being able to just "vertical-align: middle;" inside divs for the last 30 years must be billions of dollars.
Also does anyone remember the fade of the overline style on :hover links? It must has been around the IE4 or IE6 era.
Tables were also used to make divs and buttons with rounded corners, but that was true into the 2000s as well. The agony of designing and splicing them in Photoshop and putting them in table cells...
It's hilariously stupid.
No no, it's going to take our jobs!
/s
Why do so many hackers have so much difficulty seeing that the current state of public LLMs is not the pinnacle of AI technology? Nobody ever even claimed that they were.
From writing sql boilerplate to copy-pasting my entire pico8 game and going “add repulsion force to enemies so they don’t clump up on one tile” to using it to provide examples instead of synthesizing them from a manpage, it’s insanely good.
It marginally increases my productivity and reduces some friction, honestly I'm more than happy for it to write as much code as it can on my behalf, it just can't.
I suspect those for whom it is a big game changer, were likely engaged in lots of activity which is cookie cutter.
How much we were held back by backward compatibility before useful standards for things came ... But nowadays I just ignore non-standard styling. Just use the standard, because support is sufficient and browsers not supporting the standard sufficiently to make the website unusable are rare. By using the standard one also gives their developers a set target to get implemented.
so while "technically" flex was available at the time it wasn't really widespread yet.
I think there was a Chrome developers blog post about it recently.
Don't miss those days.
I remember that being far harder than it needed to be. I was a child though so maybe I just didn't get CSS well enough.
Flexbox today is better IMO.
To solve that, there's svh (small), lvh (large), and dvh (dynamic).
If you want to make a div stretch to the height of the window, so that something can appear exactly at the bottom before scrolling,
{ height: 100vh; height: 100svh; }
works best... the first line is there as a fallback for the few browsers that don't yet support svh... and if svh is supported it will replace the first line.
body {
display: grid;
grid-template-rows: auto 1fr auto;
min-height: 100dvh;
}
main {
display: grid;
align-content: center;
}
Wasn't there a Photoshop-adjacent tool that did the slicing for you? I remember a print designer on my first job feeding what was, essentially, a full-bleed leaflet design through it, and producing a "landing page" with hundreds of table cells.
I think that’s what you’re remembering.
https://en.m.wikipedia.org/wiki/Adobe_Fireworks
A page I have for one community project still uses those Imageready generated maps :)
She was great to work with.
Wasn't an image with a click <map> easier? I wasn't old enough to write very complicated html pages so my experience is lacking here.
I still remember learning to make the layout of a whole page as a table layout in school, with images in table cells for drawing nice borders around sections of the website. And we did that with GIMP!
I kind of wish that attention to detail for payload size was more common today.
it's solving a different problem
it's referring to using a 9-cell table to make an element where the corner sizes stay static, while the middle column and middle row stretch horizontally and vertically respectively to match the size of the central cell (which e.g. has variable length text)
then with background image tiling in the left/right and top/bottom middle cells you can get an effect like a drop-shadowed panel that sizes responsively
you'd probably set the flexible cells to width=100% and then have a 1-pixel gif in the edge cells to enforce the desired min-width
I was sad the article didn't mention anything about the 216-colour "web safe" palette, but perhaps the author wasn't old enough to remember having to support users with < 24-bit colour displays... or when 1024x768 took over from 640x480 as the min screen size, allowing use of fixed-width layouts >600 pixels (the max possible: 640, minus browser default page margin, minus scroll bar)...
Macromedia had this crazy system where you could slice your art up in Fireworks, and then ask it to generate the HTML and Javascript, then you could fine-tune it in Dreamweaver.
It was a mess.
> Not true anymore (edit: didn't see the 2014) but the productivity cost of not being able to just "vertical-align: middle;" inside divs for the last 30 years must be billions of dollars.
Even back then (possibly even back in the 90s? I know this existed in the 2000s) we had "VALIGN=MIDDLE" inside table cells.
All of the vertical align, layering, etc hacks came from people not wanting to use tables anymore and divs (and other block elements) finally becoming more usable. Those hacks were the growing pains of an entire shift in paradigm.
Have you checked how HN does layout?
Trying to hack a table layout together often led to frequent edits and initial attempts to maintain clean layout comments ended. You're left with never ending <tr><td><tr><td><tr><td> that you hopefully at least indented to maintain sanity. But god help you if your stumbled into another person's table layout code...
Spending time just entering "here", saving the file, and seeing where the "here" shows up. By the time 5pm rolled around "here" often turned into something like "ass" or "fuck", or if it's really bad "fuck you". IYKYK
Like, cool that we can now do rounded corners in CSS but why can't I vertically align in a div yet? (this was before flexbox)
i remember when that was all the rage. So much time spent on freaking corners...
One of my favorite CSS hacks, it doesn't always work in every single situation though...
div { display: table-cell; vertical-align: middle; }
Feels dirty at first but separation of concerns is still enforced, and I can't see any other downsides.
And CSS is still way more complicated than good old tables.
I was an early CSS supporter but man, didn't the boffins screw up that one.
<div class="row"><div class="col">
https://www.youtube.com/watch?v=BvyHEijg59A
https://css-tricks.com/snippets/css/a-guide-to-flexbox/
I also use the non-breaking hyphen for this, which is a different char than the regular hyphen or the em/en dash.
> 1x1.gif let you push elements all around the page effortlessly. To this day it is the only way to vertically center elements
If you can think of another way to vertically center, I’d like to hear it.
Yes, this is the correct usage of . That's much saner than using it as a spacing tool.
For your pleasure, here’s how to do a marquee in pure CSS:
@keyframes marquee { 0% { transform: translateX(100%); } 100% { transform: translateX(-100%); } }
.marquee-container { white-space: nowrap; overflow: hidden; position: relative; animation: marquee 10s linear infinite; }
.marquee-content { display: inline-block; }
<div class="marquee-container"><div class="marquee-content">Microsoft™ Internet Explorer™ 4.0!</div></div>
Then the navigation "rows" the entire site across the screen.
Also back then (up until ~2005) browsers were hilariously insecure. For example I was in a forum of a local youth club and you could have signatures that were displayed under every post so I added some edgy image linked from my own webserver.
Some day I accidentally put the whole folder on a password protection which prompted the "username password" login window on every page my signature was linked to. FOR ALL USERS.
I realized users would think that the forum software would ask them to log in again for some reason so I basically got all passwords of people in the forum in plaintext on my webserver.
Crazy times
Or having some javascript code in the page loaded by the iframe which could call some parent. function.
Also did I tell you about CSS-only triangles ?
The dotted underlines look nice, but I guess the is just something I used to add to work around layout quirks in Internet Explorer except I never bothered figuring out in which places they're no longer needed...
As far as I can remember, FrontPage was pretty nice. I built my first home page with it. I wanted to (visually) best all of my friends on IRC. So I designed how I wanted the page to look in (an obviously pirated copy of) PaintShop Pro. A sort of an embossed oval with navigation links on the perimeter, with all the page content appearing inside the magic oval.
But to wrangle such layout to HTML was not easy in the late 90s. I eventually managed to find out that other pages used <table> elements to force position stuff. FrontPage allowed me to stitch the individual images from PSP to a table in a WYSIWYG environment - I don't think teenager me would have had the patience nor understanding to ever do it without FrontPage. When I evenetually got it to render without glitches in IE I was _so_ proud.
The only complaint to my GUESTBOOK I got was from some guy using "lynx" (a CLI web browser) who said navigation was impossible. I only later learned about the "alt" attribute for non-visual users. Not sure if FrontPage would've even allowed me to set it though.
N+1 still loves those 1x1 transparent GIF for newsletters.
I remember how shocked my friends looked whenever they came by and saw it open on my screen. They never understood why I spend hours on that thing instead of just playing games.
The first time I thought about learning to code was when I visited Linkin Park's website. Sure, it took 10 long minutes to load but it was a masterpiece of its own.
I'd just open the website and stare at it. And one day I just decided that I'm going to make one myself. I'm trying still...
https://web.archive.org/web/20011202145112/http://linkinpark...
I tried to look it up, but the only copy that have a bearing resemblance to what I remember doesn't load very well as many files seem to be missing. And, the snapshots after that one just keep returning a 302 error :/
Which also reminds me; did anyone actually use the FrontPage Server Extensions they had for it? I remember the tool having a bunch of dynamic features like counters and guestbooks that relied on them being installed, and web hosts sometimes having these extensions listed in their features, but I never saw any sites actually using them.
Shortly after, I discovered that there's a function capable of listing folders and files from the visitor's hard drive. No permissions needed. The browser just had full access to the hard drive.
Naturally, I wrote a script and loaded it on the homepage of my website. The goal was to save, on a file, the contents of visitors hard drives' contents.
For some reason that never worked. But yeah, the internet back then was a very scary place.
It was just Microsoft's name for JavaScript because they didn't want to deal with Sun's trademark, but they did add a sprinkle of their own extra stuff in there without talking to any other implementers about it. That was par for the course for Microsoft of the day though.
Or have ChatGPT give you the same quality of learning, and with the same authoritative tone.
Don't worry, you got this. Web development has become a lot simpler since then, after all.
align-items: center;
Since HTML emails were also the rage, and email clients updated much slower than browsers, this technique was used well into the 2010s, if you wanted your thing to be displayed correctly.
No no, the middle cell contained the tiled background image, of course!
And drop shadows!
I think Apple popularized the return of rounded corners in software with the iPhone X launch, when rounding the corners of smartphone screens became popular.
macOS rounded the window corners more, I think with Big Sur. And Microsoft followed suit in Windows 11.
I remember slicing and dicing up the rounded corners in photoshop.
Before using tables for rounded corners, I remember playing with a multi-chat app called Trillian (which handled yahoo chat as well as ICQ and others). It could be skinned to your liking in much the same way you were dealing with rounded corners. The top and side cells were repeating images so resizing the window would work well.
The great an mighty Oz's crowning achievement. Ok, maybe the iPhone was bigger.
https://i.imgur.com/CJGcSeb.png
Unfortunately, you then had to figure out what to do if someone accessed the frame page directly, since search engines could still index these parts of the page seperately. And they always felt jarring and awkward too, since the cutoff between sections was always obvious...
and not exactly the same across different browsers.
Yes kids, there was a time when not everybody was using the same browser.
Here's hoping for another one, just to keep them on their toes.
Unfortunately, it is still used for html formatted emails
Add this how more complex emails could potentially lead to security issues for their webmail clients and waht not...
And well, "eh, good enough" is probably the order of the day.
In fact, I used them too around 2001 or so for my website when I did not enough programming/scripting to add a common layout to all content pages. That's how I originally implemented a two column layout: a narrow frame on the left for navigation links and a wide one on the right for content. I don't do it anymore, of course. I do know how to program now and generate my HTML website using a tiny Common Lisp program that adds common headers and footers to all my web pages.
Seriously though, why can HTML not have a client side include?
window.top.callbacks[number]("serializedData™)
In the latter 90s. Would also client render navigation frames at the time. Wicked fast compared to most web apps at the time.
Fix that and give us HTML tables with basic features built-in and datasource-backed tables + list views back in the mid ‘00s and mind-boggling amounts of time and money could have been saved.
Instead, none of that happened, and it still hasn’t.
Don’t even get me started on how much money could have been saved if the Web had adopted payment standards so that the browser itself could handle payment input.