Working with images

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

• Images in HTML | MDN
  Pretty good overview.

• Choose the right image format - web.dev
  Also discusses “Retina/High DPI” (HiDPI) screens.

Remember that images weren’t a part of the early web, and so,—like CSS—feel somewhat “bolted on” and are still somewhat tricky to work with. 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 or pixmap 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">

(There is no closing tag; this is just a standalone tag.)

[…]

Let me know what you think…​…​…

Marc Andreessen

(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.)

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

 .jpg / .jpeg Joint Photographic [Experts] Group

Ancient-but-timeless raster/bitmap format that remains a good choice for photos. JPGs 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 GIFs (if you don’t need animation) and JPGs (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 PNGs 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 SVGs, up next.) You can save photos as PNGs, but they will be much larger than JPGs. 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! SVGs should be used for any icons, logos, or illustrations where you have access to the original source artwork for the vectors (shapes).

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.

When targeting (or directly editing) SVG contents, note they have slightly different syntax than HTML/CSS—using fill and stroke instead of color and border, for example. Also remember that width and height attributes will fix the SVG size (just like <img>); use the viewBox attribute if you want them to scale.

Everyone says S-V-G.

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.">

A JPG in the same folder as the HTML (relative path/URL). Always write an alt text for accessibility.

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

Most resets (like ours) include a max-width: 100% for images—otherwise they would poke out of their containers, by default!

This intrinsic/inline behavior is rarely what you want—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 HiDPI (a.k.a. retina, 2x, 3x) screens—which is most of us, these days.

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 doesn’t work well in our modern, responsive, many-device-width context. We don’t do this much anymore.

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:

object-fit

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 usually used when setting an <img> to fill a container:

aspect-ratio

Recently 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!)

This is not just for images (you can use it on anything!), but commonly comes up when using them:

background-image

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.

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:

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:

picture, source, and 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 src file is rarely ideal at both 375px and 2560px.

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 element.

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:

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.

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