Working with Images

A thousand words?

Let’s look at the specifics around using images on the web! (Finally.)

HTML Images – MDN
Pretty good overview.
Choose the Right Image Format – web.dev
Also discusses Retina/High DPI (Hi⁠DPI) screens.

Remember that images weren’t a part of the early web, and so⁠—much like CSS⁠—can feel somewhat “bolted on” and are still often tricky to work with. (Our guy Tim Berners-Lee was even reticent). It has gotten much better recently, though!

I’d like to propose a new, optional HTML tag: IMG

Required argument is SRC="url".

This names a bitmap file for the browser to attempt to pull over the network and interpret as an image, to be embedded in the text at the point of the tag’s occurrence. An example is:

<IMG SRC="file://foobar.com/foo/bar/blargh.xbm">

…

Let me know what you think.⁠.⁠.⁠.⁠.⁠.⁠.⁠.⁠.

Marc Andreessen, 1993

(I DON’T KNOW IF WE TOLD YOU, BUT HTML USED TO SHOUT.)

Image Formats!

There are several commonly used image formats on the web, each with their own purpose:

.gif / Graphics Interchange Format

An early raster/bitmap format, heavily compressed with reduced palettes. It survives now because it does animations! This is the only reason to use this format, nowadays.

GIF compression is primitive and so they can quickly have huge file-sizes⁠—and can still slow down computers (downloading and rendering), even now. Be careful with these. (If you have longer motion needs, consider a proper video element.)

We say GIF with a hard G (as in gift), and we are your instructors and are right.

.jpg / Joint Photographic [Experts] Group

Ancient-but-timeless raster/bitmap format that remains a good choice for photos. JPG⁠s can compress images down to much, much smaller file-sizes with adjustable, lossy compression ratios.

The combination of busyness and blurriness in photos tends to hide the resulting compression artifacts better than simple illustrations/graphics, so JPG lives on as a common, widely-used image format. When you are looking at a photo online, it is almost certainly a JPG.

Folks pretty much always call these jay-pegs.

.png / Portable Network Graphics

Still raster/bitmap, but better than GIF⁠s (if you don’t need animation) and JPG⁠s (if you don’t care about file-size) as they can use lossless compression⁠—meaning they won’t leave crunchy edges around high-contrast areas.

They also support alpha-channel (partial/smooth/aliased/masked) transparency, letting you overlay things on other backgrounds.

You’ll often use PNG⁠s for illustrations and graphics⁠—things with large areas of repeated colors⁠—or where you need exact color accuracy, or the transparency. (But many of these should be SVG⁠s, up next.) You can save photos as PNG⁠s, but they will be much larger than JPG⁠s. It’s a good “utility” format.

Many people use the acronym; you’ll also sometimes hear pings.

.svg / Scalable Vector Graphics

Finally, a vector format! SVG⁠s should be used for any icons, logos, or illustrations where you have access to the original source artwork for the vectors (shapes). You can also “hand” draw them yourself, in code! More on that below.

They store the vectors in code (a bit like HTML, we’ll see), and can be scaled cleanly for different sizes/resolutions. You can also target them with CSS, if they are inlined (embedded) directly into your DOM.

Everyone says S-V-G.

“Modern” Formats

After years of discussion and competing standards, several “modern” replacement formats are starting to gain browser support and developer/designer traction. They are all designed to overcome the various shortcomings of the legacy formats above⁠—usually around compression efficiency. But it’s still a confusing, evolving mess out there! Here are some you might encounter:

AVIF: AV1 Image File Format, the new(est) replacement for everything. It… might be the next big one.
HEIC/HEIF: High Efficiency Image File Format, intended to replace JPG⁠s⁠—you might have seen .heic from your iPhones, annoying folks.
JPEG XL: I guess the “L” is for long-term? This is a competitor to AVIF as the One Format to Rule Them All.
WebP: Web Picture format, Google’s been pushing this since 2010⁠—the first of these improved formats. Finally has pretty wide support.

You still can’t go wrong with GIF/JPG/PNG/SVGs, used appropriately!

Sizing and Containers

If you remember waaaay back to our HTML intro, images are a special HTML element:

						<img src="tim.jpg" alt="Tim Berners-Lee at a computer.">

The src attribute can point to a local image file (as it does here⁠—a JPG in the same directory) or an external URL! The alt provides a description for accessibility/screen readers.

Intrinsic and Inline

By default, images will scale to their intrinsic size⁠—the (1x) pixel dimensions of the file itself⁠—and are inline elements:

This image file is 250 (actual) pixels wide, and is (likely) blurry on your (probably) high-resolution display. Also note the extra space at the bottom, from display: inline; !

This default intrinsic/inline behavior is rarely what you want, though⁠—more often your image should be sized from your design, not vice-versa. Also by default the image is scaled to CSS pixels, so it is blurry on modern Hi⁠DPI (a.k.a. retina/2x, even 3x) screens⁠—which is really most of our screens, these days.

Width and Height

In the past, you would manually set an image size within your HTML via special width and height attributes:

						<img src="tim.jpg" alt="Tim Berners-Lee at a computer." width="230" height="150">

No units, even.

But this forces the image into a fixed size, which usually doesn’t work well in our modern, responsive, many-device-width contexts.

So you’ll often want to set images to display: block; , and then control their size/positioning via CSS⁠—just like any other elements. Make sure your actual actual image dimensions are (at least) roughly twice their displayed, CSS-pixel size, so nothing is blurry:

This image file is intrinsically 1600 pixels wide, plenty more than twice the container size. Nice and sharp!

`object-fit` / `object-position`

CSS also added the object-fit and corresponding object-position properties for sizing images within their containers⁠—as if the image file is a child of img. This is often used when setting an img to fill a container size set by your design:

object-fit – MDN
object-position – MDN
This used to be much harder!

Note the block-size on the section, otherwise the container would still resize to the image. Adjust the divider to see the behavior!

`aspect-ratio`

CSS also added an aspect-ratio property to control the width-to-height ratio of an element⁠—maintaining this relationship as an element scales. (This used to be unnecessarily hard to achieve. CSS heights are always weird! You kids have it easy.)

aspect-ratio – MDN
So much easier now.

This is not just for images (you can use it on any element!), but it commonly comes up when using/constraining them in your design:

Note that without the object-fit: cover;, Tim would be distorted to the ratio! Don’t distort Tim (or generally, most images) unless you really mean to.

`background-image` / `-size` / `-origin`

You can also use images as backgrounds on elements with the background-image, background-size, and background-origin properties⁠—particularly if you want to put something in front of them, like text.

background-image – MDN
background-size – MDN
background-origin – MDN
Careful with these!

However this isn’t very semantic, as it blurs the content/presentation boundaries⁠—since the image paths are moved into your CSS, and there is no alt text description available for screen-readers. So you should only use this for contextual or decorative images⁠—not actual content:

I wouldn’t use something like this as a background . Mind your legibility! And your accessibility.

`figure` / `figcaption`

Speaking of semantics⁠—HTML also has a figure element that you can use to associate an image (or other visual) with a visible figcaption description or legend. These containers formally link the meaning/context of the elements together:

figure – MDN
figcaption – MDN
Many of your images should be in figure containers.

These can also be used to group things like videos, illustrations, and diagrams with their captions. There can be multiple visuals in each figure, if needed.

Responsive Images

With regards to their layout, you make images responsive in the same way you (should) make all your page structure responsive⁠—by writing mobile-first front-end for their containers. You can change their flow, size, shape, and so-on⁠—all via the box you put them in.

But using images introduces some additional considerations, going across breakpoints. You might want to serve/show different images at different sizes⁠—whether for dimensional (file-size, bandwidth, performance) or art-direction (scale, crop) reasons.

The exact same image file is rarely ideal at both 375px and 2560px.

`picture` / `source`

Our venerable <img> element added some control for this with the addition of the srcset and sizes attributes. But we think it is much easier (at least ergonomically) to skip right into using the modern picture container element.

picture – MDN
source – MDN
These containers/children allow you to make your img responsive.

The <picture> element is a wrapper/container for an <img>, giving it alternate <source> tags that offer different image files for different scenarios. They use media-query-like syntax to change what image is loaded and displayed:

This is all in the HTML; there is no (relevant) CSS. Adjust the divider to see the swaps!

Note that you still include the <img> as a fallback⁠—put your largest size there. We’ve found it helpful to follow the same mobile-first philosophy here as you do in the rest of your code⁠—putting your smaller images first, and your larger lower. You can have as many <source> elements as you need⁠—for image sizing, crops, or both.

Unlike CSS’s cascade, though⁠—the browser stops at the first “matching” image! (So it doesn’t download any unnecessary files.) Thus we use width < limiting queries here, instead of our usual >.

Responsive images (like the rest of this) can get very complicated, very quickly⁠—so always start with the basics (and mobile) first.

SVGs for UI

SVG⁠s are a (digital) designer’s best friend⁠—mixing the adaptability and maintainability of code with the freedom and flexibility of visual design.

Including Vector Graphics in HTML – MDN
Good overview.
How to Code SVG Icons by Hand
Aleksandr Hovhannisyan goes deep on making SVG⁠s. This is how the Pros do.

Anything you can draw in Figma (or Sketch, or Illustrator before it) lends itself to this hybrid representation. It’s common to export out .svg vector work from a design program, but you can also create (or at least edit) these files yourself⁠—just like any other code:

						<svg width="48" height="40" viewBox="0 0 48 40" xmlns="http://www.w3.org/2000/svg">
	<line x1="2" y1="20" x2="44" y2="20" stroke="black" />
	<polyline points="26,4 44,20 26,36" fill="none" stroke="black" />
</svg>

In addition to being our only vector/scaleable format, SVG⁠s have another trick up their sleeve. You can use the files as a src, like all the examples above⁠—but their code can also be included directly into your HTML! This is called inlining (though some folks say embedding):

Be sure to look at the styles.css⁠—targeting the SVG nodes just like any other HTML elements!

When targeting (or directly editing) SVG contents, note they have slightly different syntax than HTML/CSS⁠—using fill and stroke instead of background-color and border, for example. Also remember that width and height attributes will set the default SVG size (just like on an img)⁠—but you can override this with your styles.

Fills and strokes – MDN
HTML/CSS are nothing if not inconsistent.

A picture is often said to be worth a thousand words. Similarly, an interface is worth a thousand pictures.

Ben Shneiderman, 1999