Responsive

Here are the CSS ingredients we used for a media-query-less card component:

• The clamp() function helps resolve a “preferred” vs. “minimum” vs. “maximum” value.
• The flex-basis property with a negative value decides when the layout breaks into multiple lines.
• The flex-grow property is used as a unit value for proportional growth.
• The vw unit helps with responsive typography.
• The  object-fit property provides finer responsiveness for the card image, as it allows us to alter the dimensions of the image without distorting it.

tl;dr: browsers now prevent layout shifting when images load using the inline width and height values, provided that you use the correct CSS properties when making images responsive.

Layout shifts are very disrupting to the user, especially if you have already started reading the article and suddenly you are thrown off by a jolt of movement, and you have to find your place again. This also puts extra work on the browser to recalculate the page layout as each image arrives across the internet. On a complex page with a lot of images this can place a considerable load on the device at a time when it’s probably got a lot of better things to deal with!

The traditional way to avoid this was to provide width and height attributes in the <img> markup so even when the browser has just the HTML, it is still able to allocate the appropriate amount of space[:]

Then the render [should happen] like below, where the appropriate amount of space is set aside for the image when it arrives, and there is no jarring shift of the text as the image is downloaded:

Even ignoring the annoying impact to the user in content jumping around (which you shouldn’t!), the impact on the CPU [of layout shifts] can also be quite substantial.

[…]

So, once we add the dimensions and [max-width: 100%; height: auto;], we get the best of both worlds, right? No layout shifts, but also the ability to resize images using CSS? Well until very recently you might have been surprised to find out the answer was in fact: no (I was — hence why I decided to write this article).

[…]

This affects any page where we constrain the image size in a responsive manner — i.e. small screen mobile devices. These are likely to be the very users suffering with network constraints and limited processing power that will suffer most from layout shifts! Of course, we ideally should be delivering appropriately sized images for the screen size, but you cannot cover every device size, so often images will need some resizing by the browser, particularly on mobile.

[…]

[I]f the following four conditions are true, then the correct image dimensions could be calculated without needing to wait for the images to download, and so without the need of a content layout shift:

• height is set on the element in HTML
• width is set on the element in HTML
• height (or width) is set in the CSS — including using percentage values like max-width: 100%;
• width (or height) is set to auto in the CSS.

If any one of these were not set, then the calculation would not be possible, and so would fail and be ignored and have to wait for the image to be downloaded.

[…]

So instead [of waiting for a new CSS property], [browsers] could implement the equivalent logic deep in rendering code rather than exposing it via the user-agent stylesheet, but the effect is the same.

[…]

Firefox went ahead and did this as an experiment and then turned it on by default for Firefox 71. Once that was released, then your site may well have just got faster for free — thanks Mozilla!

[…]

After Firefox’s successful experimentation, Chrome also decided to implement this (again using the layout coded method for now rather than default user-agent stylesheet), and rolled it out by default in Chrome 79. This also took care of the other chromium-based browsers (Edge, Opera and Brave, for example). More recently, in January 2020, Apple added it to their Tech Preview edition of Safari, meaning it should hopefully be coming to the production version of Safari soon, and with that, the last of the major browsers will have implemented this and the web will become better and less jolty for a huge number of sites.

The term brutalism is often associated with Brutalist Architecture, however it can apply to other forms of construction, such as web design.

[…]

The term brutalism is derived from the French béton brut, meaning “raw concrete”. Although most brutalist buildings are made from concrete, we’re more interested in the term raw. Concrete brutalist buildings often reflect back the forms used to make them, and their overall design tends to adhere to the concept of truth to materials.

A website’s materials aren’t HTML tags, CSS, or JavaScript code. Rather, they are its content and the context in which it’s consumed. A website is for a visitor, using a browser, running on a computer [or mobile device] to read, watch, listen, or perhaps to interact. A website that embraces Brutalist Web Design is raw in its focus on content, and prioritization of the website visitor.

Brutalist Web Design is honest about what a website is and what it isn’t. A website is not a magazine, though it might have magazine-like articles. A website is not an application, although you might use it to purchase products or interact with other people. A website is not a database, although it might be driven by one.

They list the following principles:

• Content is readable on all reasonable screens and devices.
• Only hyperlinks and buttons respond to clicks.
• Hyperlinks are underlined and buttons look like buttons.
• The back button works as expected.
• View content by scrolling.
• Decoration when needed and no unrelated content.
• Performance is a feature.

This is one of the best responsive navigation menus I’ve seen, implementing the priority+ pattern while mixing in drop-downs and other features.

This isn’t in Drupal core yet, and may never be in this exact design, but I think it’s a pretty decent example of how to handle complex forms on the limited screen size on mobile devices and could be great inspiration.

This looks like an excellent, accessible starting point for the priority navigation pattern:

Or the priority navigation pattern, or progressively collapsing navigation menu. We can name it in at least three ways.

There are multiple UX solutions for tabs and menus and each of them have their own advantages over another, you just need to pick the best for the case you are trying to solve. At design and development agency Kollegorna we were debating on the most appropriate UX technique for tabs for our client’s website…

We agreed it should be a one-liner because the amount of tab items is unknown and narrowed our options down to two: horizontal scroll and adaptive with “more” button. Firstly, the problem with the former one is that horizontal scroll as a feature is not always visually obvious for users (especially for narrow elements like tabs) whereas what else can be more obvious than a button (“more”), right? Secondly, scrolling horizontally using a mouse-controlled device isn’t a very comfortable thing to do, so we might need to make our UI more complex with additional arrow buttons. All considered, we ended up choosing the later option[.]

Want to see a really interesting use of media queries? Open Lynn Fisher’s site in a desktop browser and resize the window, or watch this (crappy and choppy) video I took of myself doing that:

WebKit now supports the prefers-reduced-motion media feature, part of CSS Media Queries Level 5, User Preferences. The feature can be used in a CSS @media block or through the window.matchMedia() interface in JavaScript. Web designers and developers can use this feature to serve alternate animations that avoid motion sickness triggers experienced by some site visitors.

To explain who this media feature is for, and how it’s intended to work, we’ll cover some background. Skip directly to the code samples or prefers-reduced-motion demo if you wish.

The idea here is: push the container to the exact middle of the browser window with left: 50%;, then pull it back to the left edge with negative -50vw margin.

Exposing long navigation menus on small screens is tricky. Hamburger menus are everywhere, although often discouraged. Displaying “just enough” navigation at every breakpoint can feel like an impossible task. This is especially true for template developers needing to accommodate an arbitrary number of menu items.

The Priority+ design pattern seeks to display as many items as possible given an arbitrary screen width, while making the rest accessible via a single click. I’ll go over the implementation I worked on at Goshen College that includes both dropdown menus and horizontal scrolling, which I’ve yet to find in the wild: