It is interesting to think about the socio-technical reasons to make a serverside roundtrip for each keypress. Another approach might be to load up the dictionary client-side and use javascript to swap letterforms in various pre-determined locations. Presumably using browser-text with a transparent background wouldn't sufficiently simulate what the real product looked like.

▲

adrianmonk 31 minutes ago | parent | next [-]

It helps that it's not very big. In the working demo, the image is 132x26, and the actual JPEG file size is about 2-4 kB (depending on the text).

So even on a 56k modem, it might take less than 1 second to load each image.

You could also optimize it so it skips intermediate images if the user types fast. Suppose the user mashes "12345" in a fraction of a second. You start loading "1.jpg" on the first keypress. When you've finished loading "1.jpg", the field contains "12345", so skip straight to loading "12345.jpg".

The demo page's JS doesn't seem to include any optimization code like that. It just updates the img src whenever the text changes. Yet my browser seems to do it automatically! If I mash several keys, the console network log shows only some intermediate images get loaded.

I guess the browser is smart enough to know that, by the time it would have started the download, the resource no longer exists in the page. I'm not sure if browsers ~20 years ago did this, but it would have been worthwhile given how slow networks were.

▲

madaxe_again 2 hours ago | parent | prev [-]

Basically, it was easier. Or even... barely even possible to do what you describe. Maybe you could, but it would have been nightmarish whack-a-mole, and a good chance that the next update to any given browser would break it completely.

In ‘05, you had IE6, plenty of folks still on IE5, IE5 for Mac was still in use (don’t be fooled by the name - it did not behave like IE5 on windows), safari was 2.0, respectable but still a minority browser, and Firefox was on 1.0. Plenty of folks were still on Netscape navigator, which by that point was actively decomposing.

IE6 was what you built for, as it was the majority browser by a country mile. Transparency was hit and miss. Alpha PNGs just weren’t supported, you had to hack them in via JS.

Most websites were laid out using <table>. Using a <div> was new and exotic.

Oh, and you could only do custom fonts using… flash. sIFR, if you want to delve into the hell that was web dev back then. Most folks would just end up with TNR. Transparency on sIFR you could only achieve by replicating your background into the SWF, and good luck getting it to line up.

So. Support an absolute soup of edge cases across a bunch of different browser engines, and deal with “IT LOOKS NOTHING LIKE IT DID ON THE WEBPAGE” from customers, or just do it server side.

Also, it was perfectly acceptable to wait for a website to load - 50% of the U.S. was still on dialup, and “broadband” was commonly 512k.

▲

whstl an hour ago | parent | next [-]

I remember transparency was handled with gifs back then, which had their own problems and limitations.

Alignment was either done via position: absolute or by using a table. The animated background here would be a bit more complicated with a table.

Risk of it breaking with some upgrade, or looking different for some people? As you said, very likely.

So server-side image generation was indeed the best option. And it was a popular and widely solved problem, even in the 90s: visit counters that showed the visits in the shape of an image were super popular.

	▲	madaxe_again an hour ago \| parent [-]
		Yeah, transparency on gifs is binary, so you always had a crunchy edge. Plenty of use cases, but nice looking text wasn't one of them. And position: absolute did not behave the same way across IE, NN, FF, or safari. For some reason I feel the sudden urge to have a drink. Just don't tell the kids about how eCommerce used to work. Credit card number in an email, courtesy of Mal's eCommerce? Pretty much industry standard. shudders, swigs

▲

ssharp 2 hours ago | parent | prev | next [-]

Lots of things were different on the front end back then:

- IE was an albatross around every web developers neck - Even better browsers like Firefox and Safari had tons of inconsistencies - jQuery and Prototype weren't around yet - CSS is not remotely close to what it is today

Honestly, placing text over an image was a lofty task back then. We used to use lots of images with text as part of the image. Text images and table layouts were two of the main ways to get around all those cross-browser issues.

▲

adolph 19 minutes ago | parent | prev [-]

Oh yeah, I forgot what the table layout stuff used to be like. Since the back has a shine gradient across the back, each position would need all the possible characters. iirc, in that period an article on A List Apart [0] proposed something like that. I think they were doing curved box corners and sending all corners in the same file and using background positioning to only show the portion of the image depicting that corner. As I scan the article it is heavy on CSS positioning, which is used in the demo but I recall IE5 had quirks.

How true to period is the demo? I see in the source "I've tried to preserve the core of this code as it was when I wrote it in June 2005." but most of the page is a static image in the background.

0. https://alistapart.com/article/sprites/