Although I’m not sure 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 materials that are functional on products that have not yet been created?
Flash, Photoshop, and flexible pattern
Photoshop was my go-to program when I first started creating blogs. I created a 960px paint and set about creating a design that I would eventually lose information in. Set widths, fixed heights, and total placement were the keys to pixel-perfect accuracy during the development phase.
Ethan Marcotte’s speak at An Event Off and later content” Responsive Web Design” in A List Off in 2010 changed all this. As soon as I learned about responsive 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 reactive style didn’t help my fear. My second project was to get an active fixed-width website and make it reactive. What I discovered the hard manner was that you can’t really put adaptability at the end of a job. To make smooth design, you need to prepare throughout the style stage.
a novel architecture process
Developing flexible or smooth sites has always been about removing limitations, producing material that can be viewed on any system. I first used local CSS and utility classes, but it now relies on percentage-based layouts:
.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 little- 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 many more with washable pieces.
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 already exist” 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 bogus sun or our lord?
Container concerns have long been touted as an improvement upon advertising questions, but at the time of writing are unsupported in most computers. There are workarounds for JavaScript, 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 development of a component-based design that can be used on any device of any size.
In other words, responsive components to replace responsive layouts.
Container queries will enable us to design components that can be inserted in a sidebar or 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. We will still require predetermined breakpoints, so this approach will always be restrictive. 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?
The container’s dimensions shouldn’t be the design’s, but rather the image should.
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, and they would increase the possibilities for reuse and design at scale. 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 directly related to page markup, allowing for changes or additions to content without further development.
This is a significant improvement when it comes to developing designs that allow for dynamic content, but CSS Subgrid is the real game changer for flexible designs.
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 way, but… don’t ever make it smaller than the content that is inside of it.”
—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.
We can now make designs that can fit the content in them, the inside of them, and the content around them. With an intrinsic approach, we can construct responsive components without depending on container queries.
Another 2010 moment?
This intrinsic approach should in my view be every bit as groundbreaking as responsive web design was ten years ago. It’s another instance of “everything changed,” in my opinion.
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 using 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 “frame” 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 the benefit of having a selection of units is a hindrance when it comes to creating layout templates, intrinsic design and frameworks do not go hand in hand 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 reacting to content and layout flexing as needed? 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 implement 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 the dated markup tricks below,
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 switch from a left-to-right to a 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 the addition of native logical properties, there is no longer a need to rely on Sass ( or a comparable tool ) and pre-planning that would have necessitated 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 % ( the preferred value ) of its container, with no exceptions for 300px and 600px.
With these techniques, we have a content-first approach to responsive design. We can distinguish between markup and content, which means that user modifications will not 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 address device flexibility by changing our approach, designing around content and space, and responding to what we’ve already discussed. But what about that last bit of Jeffrey Zeldman’s quote,”… situations you haven’t imagined”?
Rather than someone using a mobile phone and moving through a crowded street in glaring sunshine, it’s a very different design to be done 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, we have many options available to you.
Responsible design
” Mobile data is prohibitively expensive in some places around the world, and broadband infrastructure is sparse or absent.”
” 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 assets should only be downloaded when they are required.
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 introduces some really intriguing queries that will enable us to design for a number of other unanticipated situations in the future.
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 paired with individual properties, make it simple to create designs or themes for a particular setting.
@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 in particular 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 the customer first and allowing that customer to adapt to whatever environment surrounds them.
A lot of the CSS discussed here is about moving away from layouts and putting content at the heart of design. There is so much 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 must 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.
Unexpected design should give our users, who we serve, choice and control over how they interact with the environment.
