Responsive and device-independent presentation

Objectives

By the end of the lesson, you can say what responsive design means and what the role of the viewport is, you can choose a breakpoint on the basis of the content, you know the tools of responsive images, and you can recognize what cannot be the only way of access (hover, gesture).

Why is there no single "normal" screen?

A website today can be used on a 27-inch monitor, on a narrow phone, in a zoomed-in browser window, on a tablet in landscape, on a TV, or with a screen reader. The user can rotate the phone, open the page on a shared screen, or set a zoom. Even on the same phone model the available space can differ because of the browser's chrome, a split view, or the font size setting. If we had to design a separate page for every device, the list would never end; this is why responsive design makes a single, flexible page that adapts to the available space. According to MDN it is an approach, not a single technology; the term was introduced by Ethan Marcotte in 2010, to sum up fluid grids, fluid images, and media queries.

Device independence does not mean that the look is pixel-identical everywhere, but that the essential information and task are reachable in every relevant situation. On a restaurant's page, for example, on mobile the address, the opening hours, and booking may be primary; on a wide screen more photos and a detailed story fit comfortably. The goal is not to "dumb down" the smaller screen but to manage the order of importance deliberately.

flowchart LR
    T[Content priority] --> R[Flexible layout]
    R --> S[Narrow viewport]
    R --> N[Large viewport]
    R --> Z[Zoomed view]

The viewport and flexible space

The viewport is the area of the browser in which the web page appears. On mobile there is an important detail: according to MDN, mobile browsers by default render the page in a "virtual" viewport of about 980 pixels, then scale it down to fit the screen. This makes old, non-responsive pages readable, but ruins responsive design, because media queries tailored to a narrow width never take effect. That is why the viewport meta element has to be put into the head of the page:

<meta name="viewport" content="width=device-width">

This is MDN's recommended setting; it binds the page to the real device width. Settings that disable zooming (user-scalable=no, a low maximum-scale) should be avoided: according to MDN this is harmful for people with low vision, and WCAG expects at least 2× zoomability. (Some browsers, such as iOS 10+, ignore them anyway.) In the Lighthouse run (9.2), on the faulty page, from which the viewport meta was missing, the "viewport optimized for mobile" audit received only a partial score.

A flexible layout works with percentages, fr, minmax(), or other relative units, to adapt to the available space. CSS Flexbox and Grid are tools with which the distribution of boxes is not based on rigid, hand-computed coordinates.

Tried: rigid and flexible layout

We made two three-column pages. On the rigid page all three columns are a fixed 400 pixels wide. The flexible page uses the CSS Grid solution repeat(auto-fit, minmax(min(16rem, 100%), 1fr)). We opened both in a Chrome 154 browser in headless mode, and read out the width from JavaScript (the smallest window in this mode was 500 px):

Window width	Rigid page (3×400 px)	Flexible page
500 px	scrollWidth=1200 → horizontal scroll	no scroll, 1 column in a row
700 px	scrollWidth=1200 → horizontal scroll	no scroll, 2 columns in the first row
1280 px	no scroll	no scroll, 3 columns in the first row

The rigid layout forces 1200 pixels of content into 500 pixels, so the user has to scroll sideways; in the flexible layout the number of columns adapts to the available space: there is no device-specific number in it, and the decision rests on the readability of the content (a column at least 16 rem wide).

Breakpoints: the content breaks, not the device

A media query makes it possible for a different layout to take effect at a certain width or user setting. The points where the layout changes are called breakpoints.

@media (width >= 48rem) {
  .grid { grid-template-columns: 1fr 2fr; }
}

The wrong question is: "How wide is the iPhone?" A better question: "At what width is this layout no longer comfortably readable, or when does the navigation fit?" MDN likewise advises choosing breakpoints on the basis of the content: change where the content starts to look bad (for example lines that are too long or text broken into two words per line), and define them with relative units (em, rem). This is a more durable solution: new devices always arrive, but the fact that a card needs a minimum width does not change. A media query is not always necessary either: flexible grids, relative units, and min/max values are often enough (as the auto-fit example above showed).

Mobile-first and content-first thinking

In the mobile-first approach the base style is made for the smaller, simpler situation, then extended in larger space (according to MDN a one-column narrow layout, to which multi-column media queries belong on wider screens). This does not mean that the phone is the more important user, but that we first force ourselves to pick the essentials. Content-first is a deeper principle: first we design the order of the content and the task, and only afterwards the boxes. On a job posting, the position, the place, the deadline, and the application option should be quickly reachable; a huge decorative image should not occupy the first screen.

Images, typography, and touch targets

A responsive image is not simply a shrunken image. A high-resolution photo needlessly slows loading on a phone. HTML gives two tools:

• Resolution switching: the srcset and sizes attributes of the img element list several versions and say how much space the image fills; the browser picks the suitable one before the download.
• Art direction: the source branches of the picture element give different images (for example a narrow, portrait crop) for different widths.

<img srcset="course-480w.jpg 480w, course-800w.jpg 800w"
     sizes="(width <= 600px) 480px, 800px"
     src="course-800w.jpg" width="800" height="450"
     alt="Lecture hall at the venue of the Web Programming 1 course">

According to MDN, this must be solved in HTML, not with CSS or JavaScript, because the browser starts preloading images before processing CSS and JavaScript; srcset and picture make the choice possible before the download. Do not forget to give the width and height values (3.3, 3.4), so that the layout does not jump.

Typography adapts too. Lines that are too long are tiring on a wide monitor, letters that are too small are unreadable on a phone; line spacing, contrast (9.1), and line length matter. The user's own zoom must be respected: according to MDN, the font size must not be given in vw units alone, because then the user cannot zoom it; instead a combination of relative and viewport units is good (calc(1.5rem + 4vw)).

A touchscreen has no mouse pointer, and an imprecise finger needs a larger target area. The AA level of WCAG 2.2 expects targets of at least 24×24 CSS pixels (9.1). Important controls should be big enough, separated from one another, and clearly labeled. Let us not assume, however, that mobile is touch only: a keyboard or an assistive input device can also be connected to a phone.

Device-independent interaction

The same holds for orientation: it is rarely justified that a service be usable only in landscape or only in portrait mode.

Performance as an inclusive question

Responsiveness is not only layout. On fast office Wi-Fi and a new laptop it is hardly noticeable if a page loads several dozen large images, an external font, and tracking code. On a slow mobile network or a cheaper device this can feel like minutes. A slow page is in fact an inaccessible page for those with a small data allowance, a weak connection, or a less powerful device. That is why content priority is a performance decision too (9.4): the main information and the main action should load first.

Worked example: the event page of Kurzuspont

In the desktop view of the event page the program is on the left, a speaker photo in the middle, and the enrolment box on the right. In a narrow space the three columns cannot stay. By content priority, first the title, the time, the venue, and the "Enrol" button appear; then the short description and the program; the speaker photo and related news later. The button is shown at full width, in a well-touchable size, but is also reachable by keyboard. The navigation may collapse, but every menu item remains accessible, not appearing only on hover. On a large screen the three-column layout can return. We did not make two separate websites, but designed the sensible presentation of the same information in several amounts of space.

Common misconceptions

Statement	Clarification
"Responsive = mobile-friendly."	Mobile is an important case, but the task is wider: varying size, zoom, input, and network.
"Two breakpoints are enough: phone and desktop."	The content can also break at intermediate widths; the breakpoint is decided by the content.
"On mobile we just hide the heavy parts."	If the hidden part is needed for the task, it should be available in another form.
"A hover menu is modern, so it is good."	Not everyone can reach it with hover; keyboard and touch operation are needed too.
"user-scalable=no tidies up the mobile view."	It disables zoom, which is a barrier for the visually impaired.

In brief

• Responsive design makes a single page that adapts to the available space; without the viewport meta a mobile browser uses a virtual view of about 980 px.
• Choose breakpoints on the basis of the content, with relative units; a flexible grid (Grid, Flexbox) is often enough without media queries.
• Images need srcset/sizes and picture, and width/height.
• Hover and gesture cannot be the only way of access; zooming must not be disabled.

Review questions

1. What happens in a mobile browser if the viewport meta element is missing from the page?
2. Why is "how wide is the iPhone" a bad question when choosing a breakpoint?
3. What is the difference between the roles of srcset/sizes and picture?
4. Why can hover not be the only way of reaching a menu?

Learning resources

• Responsive design (MDN) — media queries, breakpoints, mobile-first.
• Responsive images (MDN) — srcset, sizes, picture.
• Viewport meta element (MDN) — the viewport and zoomability.