38

I've wondered this for a little while:

Why did old websites make use of so many images as UI elements? If you use the Wayback Machine to go back to some of the most popular websites in the past, you'll see that a lot of the UI elements were mostly images: buttons, headers, navigation menus, certain headings with custom fonts, etc.

Was it just easier to use images as UI elements back then instead of making them in CSS? Was CSS not as advanced or something back then? I'm a beginner developer hoping to do Full-stack development, so I'm not that knowledgeable with the history of web design, and couldn't really find anything online to help answer my weird question.

11
  • 3
    facebook didn't desupport IE6 until 2010! (and even IE7 never truly had full CSS support)
    – Affe
    Oct 7 at 16:22
  • 53
    Ahh.. It's nice to come across questions like this, a reminder that there are fresh-to-dev, non cynical people out there who genuinely don't know just how bad things were in the bad old days.. I wonder what aspects of modern web development you'll come to lament/rejoice the passing of in 15 years' time!
    – Caius Jard
    Oct 7 at 18:09
  • 8
    Y'know, in the 90's, there was no CSS, etc. :) Oct 7 at 21:08
  • 15
    We seem to have different ideas of what ‘old’ means! As far as I'm concerned, old web sites used few or no images, because they took ages to download over dial-up (and often some time for the poor 16-bit machine to decode and display). Less old web sites used many images…
    – gidds
    Oct 8 at 7:46
  • 5
    I was thinking "Because they didn't care much about accessibility" and then realised how many newer ones seem to care equally little - now choosing to hide their content behind JavaScript or private-use character etc. :-( Oct 8 at 8:21
63

Was CSS not as advanced or something back then?

This is the reason. When websites first became available, there was no CSS, and they didn't even support tables! Websites were usually designed by slicing a mockup into different pieces and hyperlinking the pieces to different places (or using one big image and an imagemap.) Remember, this was at a time when people used dial-up modems, and images took a long time to load! Sometimes one-bit placeholder images showed up while the full-color version came over the modem.

Incidentally - a lot of old websites look like image-heavy print materials/brochures, because they were developed by marketing agencies, and printed materials were the prevailing mental model for marketing information back then.

Then, tables were introduced (as well as frames), and gave designers and developers the flexibility to add non-image items to different areas of a webpage. The world needed standards, though, and different groups like the World Wide Web Consortium made official recommendations that brought us the model that breaks styling attributes (CSS) away from hypertext. (I'm old enough to remember <font> tags, and using bgcolor attributes in table cells to color the left nav of a page.)

So, the short answer is: there was a time before CSS, and then it took a few years to convince web professionals to fully adopt CSS, and that's why old websites are so heavily image-based.

18
  • 56
    The 'good' old days of "rounded_corner_top_right.gif"...
    – Duroth
    Oct 7 at 7:06
  • 41
    Don't forget spacer-10px.gif :)
    – Izquierdo
    Oct 7 at 13:34
  • 8
    I seem to remember that even when CSS was there, it wasn't possible at first to style form elements such as buttons and checkboxes. So those were sometimes replaced with images
    – Berend
    Oct 7 at 14:37
  • 22
    You'll still see this pattern in emails, since CSS support varies widely between email clients. That variance means that the best way to ensure emails (especially for marketing) look good and consistent is to use an image (or table of images) that can be expected to look the same no matter where you're viewing it. Oct 7 at 15:59
  • 14
    I think the point of "marketing agencies acted as if they were designing print materials" is vastly understated. People didn't really get the internet for a long time, and so they stuck to what they knew how to do.
    – MechMK1
    Oct 7 at 19:24
9

Specifically for UI elements - arrows, buttons, etc. - there is another factor. Font Awesome (2012), SVG (as late as 2011, depending on browser) icons (which appear to be what StackExchange currently uses) and other ways of generating high-quality icons without using image files simply did not exist. I found a fairly good explanation of the evolution here.

6
  • 1
    ah, but OP doesn't mention icons at all. and icons (even svg icons) are still images regardless...
    – user
    Oct 8 at 9:45
  • 1
    OP does say "UI elements", "buttons", "menus" - to me those are the kinds of things that Font Awesome and now SVG Icons have replaced. The difference with SVG Icons (or similar) and the old "everything is a clickable image" method is that the SVG code is (a) embedded code rather than a separate file (a separate file, even if the total size is the same as embedded, requires an extra round-trip to a server) and (b) scalable (as are fonts, but not ordinary jpg/png/gif images). Oct 8 at 12:14
  • 1
    @user don’t awesome (as the name implies) very much blurs the definition between image and text. Plus Highcharts (for example) use SVG elements to display the interactive charts. But I probably wouldn’t call the chart an “image”!
    – Tim
    Oct 8 at 13:28
  • @manassehkatz-Moving2Codidact not too sure about svgs replacing buttons and menus though... and while "ui elements" obviously includes images, i'd argue that the vast majority (borders & layout elements) are in fact not images
    – user
    Oct 8 at 16:58
  • @Tim sure but that is... completely beside the point of the question. and while technically they're images, i'm half sure it's more from convenience more than anything - two potential upsides being consistent sizing and the ability to have them in css content: properties, rather than, well, "lmao let's use fonts instead of images because why not" - note that even SE itself used spritesheets until (i believe) very recently
    – user
    Oct 8 at 17:00
6

As others have said, early versions of HTML and CSS were much more limited that what you are used today.

Consider, just taking into account Internet Explorer, which was predominant or at least a major player at the time (remember that Chrome only appeared in 2008, and only reached the 10% threshold in 2010):

  • border-radius used for rounded corners were introduced in IE9 (released 2011).

  • gradients were introduced in IE10 (2012)

  • SVG support was introduced in IE9.

So just to make a button with rounded corners, you needed to use an image!

Also remember that at the time, upgrades were a lot slower than they are now. When a new version of IE was released, you could still have waaaaay earlier versions representing a significant share of the traffic for many years: IE8 alone was still at over 10% in April 2013 (not counting earlier versions).

And that's not even taking into account the fact that, even when they all supported a feature, each browser had its own quirks (they still do, but not so much on the more basic HTML/CSS features). It was sometimes easier to drop an image which would work anywhere that to try to adjust CSSS to make it work in all browsers.

At the time, there was also less the issue of high-resolution displays (Retina and the like). Having an UI elements as an image didn't raise issue with pixelated text or buttons, one CSS pixel was nearly always one actual screen pixel.

Using images for UI elements was so ubiquitous that some techniques were developed especially for that (to reduce loading time), like sprites (having all the elements on a single image, and "cutting" pieces of that image using CSS for individual UI elements.

Note that nowadays, we still face similar issues with e-mail. HTML/CSS support in e-mail clients is often a lot more limited, and you often need to use creative alternative techniques to get a decent result. However in that case images are no longer a viable choice, as many e-mail readers block external image loading for privacy reasons, and embedded images raise other issues.

3
  • 8
    and for some reason, at a time when rounded corners and gradients were hard to make without hacky top-left-corner.gif solutions, they were all the rage in user interface designs. And by the time CSS was capable of doing it easily, we were making completely flat rectangular interfaces.
    – user46053
    Oct 8 at 16:27
  • 2
    @user46053 Completely flat rectangular interfaces that are actually harder to use than the interfaces they replaced because they lose "depth", contrast, etc. Oct 8 at 17:18
  • 1
    @user46053 It's less paradoxical then it seems at first glance - it was a technological show-off to a large extent. When it became easy to make things like gradients and rounded corners, it was no longer "cutting edge design", and people started looking for other ways to look distinct. The return to high-contrast edges and little frill was refreshing - though of course, you always found plenty of designers who just didn't get how it's supposed to be done and we got back to things like "I have no idea which of these is a button/link". Ultimately, it's about finding a language.
    – Luaan
    Oct 10 at 11:38
5

In addition to the other excellent answers here, don't forget that the early years of the Internet were plagued with great browser wars. Standards like HTML and CSS existed, but "standard" didn't mean what it means now. Browsers back then were products sold in a store, like any other piece of software. They differentiated themselves by the proprietary features that they supported or by the unique way they handled standard web elements. Companies like Microsoft participated in web standards committees not to ensure the interoperability of the web, but to steer competitors away from anything resembling their proprietary features. Many of these companies were notorious for getting features included in standards and then never supporting them. Also, many aspects of these early standards were unfortunately written in ways that could be interpreted multiple ways. That meant that in the rare instance that different browsers were trying to act consistently, there was still plenty of room for incompatibility.

On top of this, software at that time was generally bought in a store, not distributed electronically. Software updates were rare, you just had to buy the next year's release. Running software that was 4-5 years old was relatively normal. That meant the target audience for a website could be running any one of 3-4 different browsers, and each of those browsers could have 5-6 different versions in use. All of these browser/version combinations had meaningful differences that you had to adjust for. Making it worse was the corporate world's reliance on Internet Explorer. Many of Microsoft's big clients would complain loudly any time they broke existing intranet sites, even if those sites used horrendously out of date technology. Internet Explorer was therefore perpetually shackled to many of the limitations and mistakes of its earliest releases, and new technologies took a very long time to be supported.

A rule of thumb at the time was that if you spent X hours building a website, it would take you at least 5X hours to fix the compatibility issues with all the various browsers (half of that time being just for Internet Explorer). In order to stay sane, web developers would try to stick to a limited subset of web technologies that were widely supported and stable. Images provided an easy way to avoid many of these problems. Image file formats were well-established, widely-supported standards, so they looked the same practically everywhere. You didn't have to worry about Mac and PC users having completely different fonts installed, or about different OSes using different height/width ratios for native button widgets. You could prototype the UI in photoshop, chop it up into rectangles, and write HTML to assemble those rectangles in the right order.

I don't ever remember developers thinking that any of this was a good design choice, though. It was done more out of necessity. Eventually, the market for browsers as a sellable product fell apart. Free software took its place, and developers started to have more of a say about how the web works than corporate interests did. The focus shifted more towards interoperability and developer sanity, and thus the modern ecosystem is in a much better place.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.