Brief: Image v. 0.1 [Component]

Component type	Molecule
Document status	READY
Design source (in Figma)	Image component
Author	@nathan.mckean@reckitt.com (Unlicensed)
Responsible	@Julia Boyarshchikova (Deactivated)

The image component allows for the placement of a standalone image.

Note: It is not necessarily the case that a full image component, vs an image file would be used as part of wider components such as a teaser. The image component mentioned here is intended to allow for the manual entry of a content image as is common within articles. Whether it allows decorative imagery is TBC.

Use When

You want to place imagery on a page, usually to enhance an article.

Don’t Use When

X

Related/Similar Components

Whilst imagery exists within other components, it is not necessarily the same as a standalone image component.
Though icons and pictograms are similarly visual to images, icons will generally be SVG files and will be linked to a specific contextual preset (e.g. back, next, download, facebook, etc). Pictograms will also likely to be SVG, will be purely decorative, and though not specially linked to a context like icons, they are likely to be chosen in the CMS from a pre-defined global set (not uploadable like images).

Key Content

Item	Type	Notes
Image Asset*	Media
Image Description*	Single line text	Used as alt text where appropriate
Caption	Single line text
Link	URL or Page/Node
Link Description	Single line text	Used as alt text where appropriate

Visual Style

Captioning Images that include a caption will display the caption visually after the image.

Aspect Ratio In many use cases, imagery will sit inside a container and be cropped to suit that container (e.g. object fit: cover). In other use cases, a parent container may be constrained to an aspect ratio (either set as a universal default or content-editor-controlled) in which it will also (if necessary) crop to fit. In other use cases still, the “native” aspect ratio will need to be maintained – an example of this would be a logo or a graph.

Shape If the brand has preset a global border and border radius (across buttons and other elements), the border radius would be applied to standalone images unless this token was overridden by brand. It is unlikely that this would be individually content editable. If an aspect ratio hasn’t been defined then no radius would be applied as the image is filling the container in which it is placed – that container may though have a shape.

To be discussed How (and do we need to) control alignment within containers? E.g. Left aligned, centred, etc and do we need to set min/max widths, etc? Do we need to consider style definition for before the image is loaded? (e.g. background fill, etc. Possible updates (TBC Ekino) for hover with captions (e.g. to behave more like links and with external link definition, etc).

Behaviour

If linked, the image may take a hover state or a zoomed state (if using ‘cover’) in a similar manner to cards to give the user feedback that it is clickable. Equally the image will take the default focus behaviour (as per buttons). Linked images will not take a visited state (at least for now)
Imagery that crops to cover a container will do so around a defined focal point. In the absence of a focal point, it will default to the centre of the image.
It is assumed that image performance will be handled by ‘the system’, taking uploaded imagery and sizing and optimising as needed to deliver performant file sizes.
Images, amongst other page elements should consider lazy loading, but this forms a wider discussion.

Editorial

Ensure image descriptions are concise, but detailed enough to describe the image to a blind user so that they can picture what they cannot see.
Captions should be kept concise. Long descriptions are not currently supported (but may come outside of MVP).

Accessibility

When captions are applied the image is likely to become a <figure> with a <figcaption> so that the caption is tied to the image. A loose paragraph <p> doesn’t semantically tie the caption to the image.
Whilst a backend rather than front end conversation, when content editors place imagery, they may be required to confirm if the image is content-driven or decorative (e.g. an ‘isDecorative’ Boolean prop). Where an image is decorative, the alt tag will =””. Where the image is not decorative, the description (not caption) will be used as the alt text. Where the image is linked, the link description (e.g. Visit us on Facebook) will be used as the alt text.

Analytics & Data

None of note. If any analytics is required, it would simply be tracking of a linked heading or element visibility of the heading. This would only require that the heading be able to be individually isolated.

Future Expansion

The MVP supports a border radius, but more complex shape control will come in future expansion. This may be applied to the container of which the image then fills. We may also support the addition of a field for a SVG mask (or similar method of delivering complex shape).
It is also likely that enhancements such as filters and blend modes will be supported (whether or not they are content-editor controlled or automatically applied is yet to be determined).
Likely to be separate components (but still to be defined), imagery could be expanded to allow a ‘before/after’ slider effect. Additionally, adding clickable content areas on an ‘image map as hotspots’ may come down the line.
Standalone images may need to consider the ‘elevation’ system (and with it, shadows etc.

Wider Conversations that may impact this

Lazy loading: Images are prime for lazy loading, but lazy loading goes beyond imagery and should be discussed more widely. Items in the initial viewport for example should be “eager” with content further down the page loaded as needed.
Layout & containers: Because imagery has the ability to fill parent containers, it with similar items like text boxes need to consider any additional layout controls such as justification and alignment, etc.
Sizing: Whilst images and other elements will be responsive, do we need to try and set initial sizing (widths/heights) to cater for cumulative layout shifts, etc.
External linking: Though images aren’t the only items to be linked, some quick research is needed around “Opening in new tab” (for accessibility should generally be avoided unless there is a strong business case elsewise – and if there is, external links should be signposted visually and called out to screen-readers).