Although I’m not certain when I first heard this statement, it has over the centuries stuck in my mind. How do you generate solutions for scenarios you can’t think? Or create items that function on products that have not yet been created?
Flash, Photoshop, and flexible pattern
My go-to program when I first started creating platforms was Photoshop. I created a 960px paint and set about creating a design that I would eventually lose information in. Using set widths, fixed heights, and complete positioning, the development phase aimed to achieve pixel-perfect precision.
Ethan Marcotte’s speak at An Event Off and subsequent content” Responsive Web Design” in A List Off in 2010 changed all this. As soon as I learned about flexible style, I was convinced, but I was even terrified. The pixel-perfect models full of special figures that I had formerly prided myself on producing were no longer good enough.
My first encounter with flexible style didn’t help my fear. My second project was to get an active fixed-width website and make it reactive. You can’t really put responsiveness at the end of a job, which I learned the hard way. To make smooth design, you need to prepare throughout the style phase.
A novel method of style
Developing flexible or smooth sites has always been about removing limitations, producing material that can be viewed on any system. It relies on the use of percentage-based design, which I immediately achieved using native CSS and power groups:
.column-span-6 { width: 49%; float: left; margin-right: 0.5%; margin-left: 0.5%;}.column-span-4 { width: 32%; float: left; margin-right: 0.5%; margin-left: 0.5%;}.column-span-3 { width: 24%; float: left; margin-right: 0.5%; margin-left: 0.5%;}
Then with Sass so I could take advantage of @includes to re-use repeated slabs of script and walk up to more semantic premium:
.logo { @include colSpan(6);}.search { @include colSpan(3);}.social-share { @include colSpan(3);}
Media inquiries
The next ingredient for flexible design is press queries. Without them, content would shrink to fit the available space, regardless of whether it remained readable ( The exact opposite issue resulted from the development of a mobile-first approach ).
Media inquiries prevented this by allowing us to add breakpoints where the design could adapt. Like most people, I started out with three breakpoints: one for desktop, one for tablets, and one for mobile. Over the years, I added more and more for phablets, wide screens, and so on.
For years, I happily worked this way and improved both my design and front-end skills in the process. The only problem I encountered was making changes to content, since with our Sass grid system in place, there was no way for the site owners to add content without amending the markup—something a small business owner might struggle with. This is because each row in the grid was defined using a div as a container. Adding content meant creating new row markup, which requires a level of HTML knowledge.
String premium was a mainstay of early flexible design, present in all the frequently used systems like Bootstrap and Skeleton.
Another difficulty arose as I moved from a design firm building websites for tiny- to medium-sized companies, to larger in-house teams where I worked across a collection of related sites. In those capacities, I began to work more with recyclable parts.
Our rely on multimedia queries resulted in parts that were tied to frequent window sizes. If modify is the goal of part libraries, then this is a real issue because you can just use these components if the devices you’re designing for match the window sizes in the design library, which prevents you from actually achieving the “devices that don’t yet occur” goal.
Then there’s the problem of space. Media inquiries allow components to adapt based on the viewport size, but what if I put a component into a sidebar, like in the figure below?
Container queries: A false dawn or our savior?
Container queries have long been touted as an improvement upon media queries, but at the time of writing are unsupported in most browsers. Workarounds for JavaScript exist, but they can lead to dependencies and compatibility issues. The basic theory underlying container queries is that elements should change based on the size of their parent container and not the viewport width, as seen in the following illustrations.
One of the biggest arguments in favor of container queries is that they help us create components or design patterns that are truly reusable because they can be picked up and placed anywhere in a layout. This is a significant step in the direction of a component-based design that can be used with any device, regardless of size.
In other words, responsive components to replace responsive layouts.
Container queries will enable us to design components that can be placed in a sidebar or in the main content and respond accordingly rather than designing pages that respond to the browser or device size.
My concern is that we are still using layout to determine when a design needs to adapt. This approach will always be restrictive because we will still require predetermined breakpoints. For this reason, my main question with container queries is, How would we decide when to change the CSS used by a component?
The best place to make that choice is probably not a component library that is disconnected from context and real content.
As the diagrams below illustrate, we can use container queries to create designs for specific container widths, but what if I want to change the design based on the image size or ratio?
In this instance, the container’s dimensions are not what should be used to dictate the design; rather, the image is.
It’s hard to say for sure whether container queries will be a success story until we have solid cross-browser support for them. Responsive component libraries would undoubtedly change the way we design them, and they would increase the possibilities for reuse and scale design. But maybe we will always need to adjust these components to suit our content.
CSS is evolving.
Whilst the container query debate rumbles on, there have been numerous advances in CSS that change the way we think about design. The days of fixed-width elements measured in pixels and floated div elements used to cobble layouts together are long gone, consigned to history along with table layouts. Flexbox and CSS Grid have revolutionized layouts for the web. We can now create elements that wrap onto new rows when they run out of space, not when the device changes.
.wrapper { display: grid; grid-template-columns: repeat(auto-fit, 450px); gap: 10px;}
The repeat() function paired with auto-fit or auto-fill allows us to specify how much space each column should use while leaving it up to the browser to decide when to spill the columns onto a new line. Similar things can be achieved with Flexbox, as elements can wrap over multiple rows and “flex” to fill available space.
.wrapper { display: flex; flex-wrap: wrap; justify-content: space-between;}.child { flex-basis: 32%; margin-bottom: 20px;}
The biggest benefit of all this is you don’t need to wrap elements in container rows. Without rows, content is not tied to page markup in the same way, allowing for changes or additions to content without further development.
The real game changer for flexible designs is CSS Subgrid, which is a significant improvement in terms of designing designs that allow for evolving content.
Remember the days of crafting perfectly aligned interfaces, only for the customer to add an unbelievably long header almost as soon as they’re given CMS access, like the illustration below?
Subgrid allows elements to respond to adjustments in their own content and in the content of sibling elements, helping us create designs more resilient to change.
.wrapper { display: grid; grid-template-columns: repeat(auto-fit, minmax(150px, 1fr)); grid-template-rows: auto 1fr auto; gap: 10px;}.sub-grid { display: grid; grid-row: span 3; grid-template-rows: subgrid; /* sets rows to parent grid */}
CSS Grid allows us to separate layout and content, thereby enabling flexible designs. Subgrid also enables us to create designs that can change to fit changing content. Subgrid at the time of writing is only supported in Firefox but the above code can be implemented behind an @supports feature query.
Intrinsic layouts
I’d be remiss not to mention intrinsic layouts, the term created by Jen Simmons to describe a mixture of new and old CSS features used to create layouts that respond to available space.
Columns with percentages are flexible in responsive layouts. Intrinsic layouts, on the other hand, use the fr unit to create flexible columns that won’t ever shrink so much that they render the content illegible.
frunits is a statement that says I want you to distribute the extra space in this manner, but never that it should be smaller than the content inside.
—Jen Simmons,” Designing Intrinsic Layouts”
Intrinsic layouts can also make use of a mix of fixed and flexible units, letting the content choose how much space it occupies.
What distinguishes intrinsic design is that it not only creates designs that can withstand future devices but also helps scale designs without losing flexibility. Components and patterns can be lifted and reused without the prerequisite of having the same breakpoints or the same amount of content as in the previous implementation.
They now have the ability to adapt to the content both inside and outside of them. With an intrinsic approach, we can construct responsive components without depending on container queries.
Another 2010 moment, perhaps?
This intrinsic approach should in my view be every bit as groundbreaking as responsive web design was ten years ago. It’s another “everything changed” moment for me.
But it doesn’t seem to be moving quite as fast, I haven’t yet had that same career-changing moment I had with responsive design, despite the widely shared and brilliant talk that brought it to my attention.
One possible explanation for that might be that I now work for a sizable company, which is significantly different from the role I held as a design agency in 2010: In my agency days, every new project was a clean slate, a chance to try something new. Modern projects frequently improve existing websites with an existing codebase and use existing tools and frameworks.
Another could be that I feel more prepared for change now. I was new to design in general in 2010; the shift was frightening and required a lot of learning. Also, an intrinsic approach isn’t exactly all-new, it’s about using existing skills and existing CSS knowledge in a different way.
You can’t framework your way out of a content issue.
Another reason for the slightly slower adoption of intrinsic design could be the lack of quick-fix framework solutions available to kick-start the change.
Ten years ago, responsive grid systems were everywhere. With a framework like Bootstrap or Skeleton, you had a responsive design template at your fingertips.
Because having a selection of units is a hindrance when creating layout templates, intrinsic design and frameworks do not work together quite as well. The beauty of intrinsic design is combining different units and experimenting with techniques to get the best for your content.
Additionally, there are design tools. We probably all, at some point in our careers, used Photoshop templates for desktop, tablet, and mobile devices to drop designs in and show how the site would look at all three stages.
How do you do that right away, with each component responding to content and layout flexing as and when necessary? This type of design must happen in the browser, which personally I’m a big fan of.
Another ongoing debate centered on whether designers should code is ongoing. When designing a digital product, we should, at the very least, design for a best- and worst-case scenario when it comes to content. It’s not ideal to do this in a graphics-based software package. In code, we can add longer sentences, more radio buttons, and extra tabs, and watch in real time as the design adapts. Does it continue to function? Is the design too reliant on the current content?
I’m personally anticipating the day when a design component can truly be flexible and adapt to both its space and content without relying on the device or container dimensions.
Content first
Content is variable. After all, to design for the unknown or unexpected we need to account for content changes like our earlier Subgrid card example that allowed the cards to respond to adjustments to their own content and the content of sibling elements.
Thankfully, there’s more to CSS than layout, and plenty of properties and values can help us put content first. Subgrid and pseudo-elements like ::first-line and ::first-letter help to separate design from markup so we can create designs that allow for changes.
Instead of dated markup tricks like this —
First line of text with different styling...
—we can target content based on where it appears.
.element::first-line { font-size: 1.4em;}.element::first-letter { color: red;}
Much bigger additions to CSS include logical properties, which change the way we construct designs using logical dimensions (start and end) instead of physical ones (left and right), something CSS Grid also does with functions like min(), max(), and clamp().
This flexibility allows for directional changes according to content, a common requirement when we need to present content in multiple languages. This was frequently accomplished with Sass mixins in the past, but it was frequently limited to a left-to-right or right-to-left orientation.
In the Sass version, directional variables need to be set.
$direction: rtl;$opposite-direction: ltr;$start-direction: right;$end-direction: left;
These variables can be used as values.
body { direction: $direction; text-align: $start-direction;}
—or as properties.
margin-#{$end-direction}: 10px;padding-#{$start-direction}: 10px;
However, with native logical properties, we can now avoid relying on Sass ( or a similar tool ) and pre-planning, which meant using variables throughout a codebase. These properties also start to break apart the tight coupling between a design and strict physical dimensions, creating more flexibility for changes in language and in direction.
margin-block-end: 10px;padding-block-start: 10px;
There are also native start and end values for properties like text-align, which means we can replace text-align: right with text-align: start.
Like the earlier examples, these properties help to build out designs that aren’t constrained to one language, the design will reflect the content’s needs.
Fluid and fixed
We briefly covered the power of combining fixed widths with fluid widths with intrinsic layouts. The min() and max() functions are a similar concept, allowing you to specify a fixed value with a flexible alternative.
For min() this means setting a fluid minimum value and a maximum fixed value.
.element { width: min(50%, 300px);}
As long as the element’s width is not greater than 300px, the element in the figure above will cover 50 % of its container.
For max() we can set a flexible max value and a minimum fixed value.
.element { width: max(50%, 300px);}
As long as the element’s width is at least 300px, it will now cover 50 % of its container. This means we can set limits but allow content to react to the available space.
The clamp() function builds on this by allowing us to set a preferred value with a third parameter. Now we can allow the element to shrink or grow if it needs to without getting to a point where it becomes unusable.
.element { width: clamp(300px, 50%, 600px);}
This time, the element’s width will be 50 % of its container’s preferred value, with no exceptions for 300px and 600px.
With these techniques, we have a content-first approach to responsive design. We can’t change markup because content can’t be changed, so user modifications won’t have an impact on the design. We can start to future-proof designs by planning for unexpected changes in language or direction. Additionally, we can increase flexibility by specifying desired dimensions alongside adaptable alternatives, which will allow for more or less content to be displayed correctly.
Situation first
We can cover device flexibility by changing our approach, designing around content and space rather than catering to devices, thanks to what we’ve discussed so far. But what about that last bit of Jeffrey Zeldman’s quote,”… situations you haven’t imagined”?
It’s a lot different to design for someone using a mobile phone and walking through a crowded street in glaring sunshine than it is for someone using a desktop computer. Situations and environments are hard to plan for or predict because they change as people react to their own unique challenges and tasks.
This is why making a choice is so crucial. One size never fits all, so we need to design for multiple scenarios to create equal experiences for all our users.
Thankfully, there is a lot we can do to give people choices.
Responsible design
There are places in the world where mobile data is prohibitively expensive and where there is little or no broadband infrastructure.
” I Used the Web for a Day on a 50 MB Budget“
Chris Ashton
One of the biggest assumptions we make is that people interacting with our designs have a good wifi connection and a wide screen monitor. However, our users may be commuters using smaller mobile devices that may experience drops in connectivity while traveling on trains or other modes of transportation. There is nothing more frustrating than a web page that won’t load, but there are ways we can help users use less data or deal with sporadic connectivity.
The srcset attribute allows the browser to decide which image to serve. This means we can create smaller ‘cropped’ images to display on mobile devices in turn using less bandwidth and less data.
The preload attribute can also help us to think about how and when media is downloaded. It can be used to tell a browser about any critical assets that need to be downloaded with high priority, improving perceived performance and the user experience.
Additionally, there is native lazy loading, which indicates that only the most crucial files should be downloaded.
With srcset, preload, and lazy loading, we can start to tailor a user’s experience based on the situation they find themselves in. What none of this does, however, is allow the user themselves to decide what they want downloaded, as the decision is usually the browser’s to make.
So how can we put users in control?
The media queries are now being returned.
Media inquiries have always been about much more than device sizes. They allow content to adapt to different situations, with screen size being just one of them.
We’ve long been able to check for media types like print and speech and features such as hover, resolution, and color. Because of these checks, we can offer options that work for more than one situation. It’s less about one-size-fits-all and more about providing adaptable content.
As of this writing, the Media Queries Level 5 spec is still under development. It brings up some really intriguing queries that will eventually help us design for a number of other unanticipated situations.
For example, there’s a light-level feature that allows you to modify styles if a user is in sunlight or darkness. These features, which are enhanced by custom properties, make it simple to create designs or themes for particular environments.
@media (light-level: normal) { --background-color: #fff; --text-color: #0b0c0c; }@media (light-level: dim) { --background-color: #efd226; --text-color: #0b0c0c;}
Another key feature of the Level 5 spec is personalization. Instead of creating designs that are the same for everyone, users can choose what works for them. This is achieved by using features like prefers-reduced-data, prefers-color-scheme, and prefers-reduced-motion, the latter two of which already enjoy broad browser support. These features tap into preferences set via the operating system or browser so people don’t have to spend time making each site they visit more usable.
Media inquiries like this go beyond choices made by a browser to grant more control to the user.
Expect the Unexpected
In the end, the one thing we should always expect is for things to change. With foldable screens already available on the market, devices especially change more quickly than we can keep up.
We can’t design the same way we have for this ever-changing landscape, but we can design for content. We can create more robust, flexible designs that increase the longevity of our products by putting content first and allowing that content to adapt to whatever space surrounds it.
A lot of the CSS discussed here is about moving away from layouts and putting content at the heart of design. There is a lot more we can do to adopt a more intrinsic approach, from responsive components to fixed and fluid units. Even better, we can test these techniques during the design phase by designing in-browser and watching how our designs adapt in real-time.
When it comes to unexpected circumstances, we need to make sure our goods are accessible whenever and wherever needed. We can move closer to achieving this by involving users in our design decisions, by creating choice via browsers, and by giving control to our users with user-preference-based media queries.
A good design for the unexpected should allow for change, give choice, and give control to the people we serve: our users themselves.
