Short answer: Use <picture> when different layouts need meaningfully different compositions, not merely different resolutions of the same composition. Put media-specific crops in <source> elements and keep a complete <img> fallback with dimensions, alt text, and sensible defaults.
A wide desktop hero can place a person to the left of a headline. On a narrow phone, shrinking that canvas may make the person tiny or place text over the subject. Art direction solves the composition problem by choosing a tighter or differently positioned crop.
Art direction is not resolution switching
Resolution switching delivers the same visual content at several pixel widths. A width-descriptor srcset and accurate sizes are usually enough. The browser chooses a resource based on the slot and device.
Art direction changes the image content or crop for a layout. It may use a wide source above one breakpoint and a portrait source below it. MDN distinguishes these cases in its responsive images guide. Keeping the distinction clear prevents needlessly complex markup.
Each art-directed source can still have its own width ladder. The mobile crop might offer 480w and 720w candidates, while the desktop crop offers 960w, 1280w, and 1600w. Use the responsive width ladder to bound each set.
How should the picture markup be structured?
Order <source> elements so their media conditions express the intended precedence. Each source can include media, srcset, sizes, and optionally type. The nested <img> remains mandatory because it supplies the fallback request, semantic alt text, intrinsic dimensions, loading behavior, and other image attributes.
Do not duplicate alt text on sources. The alternatives represent the same semantic image, so the img text describes the shared purpose. If the mobile and desktop visuals communicate different information, the design may require two semantic images or a reconsidered content structure, not cleverer source selection.
The HTML Living Standard defines the picture element and image candidate model. Use standards-based markup first, then let the image API provide derivatives.
How do you create reliable alternate crops?
The best input is explicit editorial intent. Store focal coordinates, a named gravity, or approved crop boxes with the asset. Generate a small set of named transformations such as hero-wide-v1 and hero-portrait-v1. Named presets are easier to review than arbitrary crop parameters embedded in templates.
Automatic subject or face detection can be useful, but it should not be treated as infallible. Test difficult cases: groups of people, products near edges, text inside an image, transparent objects, and scenes with competing focal points. Provide an editorial override for valuable assets.
Cloudinary documents crop and gravity options in its image transformation reference. Other providers use different names and behavior, so isolate the vendor mapping behind your URL builder.
Avoid upscaling after a tight crop. A portrait crop extracted from a small source may not have enough pixels for a high-density phone. Validate the crop’s effective dimensions during ingestion or editorial preview.
Can picture also select formats?
Yes. A source can declare a MIME type so supporting browsers choose AVIF or WebP while the img supplies another format. But combining format selection, art direction, and many responsive widths can create a large candidate matrix.
Prefer service-side format negotiation when it is correctly cached and observable, or use a small explicit format stack. Whichever method you choose, ensure every art-directed crop has a compatible fallback. The site’s guide to AVIF, WebP, and JPEG helps frame that decision.
What are the performance pitfalls?
Do not preload a desktop URL while the phone selects a different source. That can download both. If the art-directed image is the likely LCP element and needs a preload, use responsive preload attributes that mirror the candidates and media logic. web.dev explains the constraints in its responsive image preload guide.
Set the fetchpriority and loading behavior on the nested image according to its role. A page’s likely LCP image should not be lazily loaded. Images far below the fold generally can be. The dedicated LCP optimization guide covers the complete discovery path.
Reserve stable space. If desktop and mobile crops have different aspect ratios, CSS can set an aspect ratio appropriate to each breakpoint. The intrinsic width and height on the fallback still provide useful default geometry.
How do you test art direction?
Review every breakpoint with real content, not only a placeholder. Inspect currentSrc to confirm the intended crop and candidate were selected. Resize through breakpoint boundaries and test direct navigation, cached navigation, and slow networks.
Automate screenshots for a small corpus of challenging assets. A visual test can reveal a subject cut in half even when the URL and dimensions are technically valid. Also validate the accessibility tree and alt text because responsive sources should not change the meaning exposed to assistive technology.
Use <picture> when composition genuinely changes. Keep the source set small, make crop intent explicit, preserve a complete fallback, and test visual meaning as carefully as byte size.
Leave a Reply