The next generation of responsive Web design: component-driven Web design

Since famous designer Ethan Marcotte (@Beep) published an article named Responsive Web Design on A List Apart, Responsive Web Design (RWD, The figure of Responsive Web Design appeared in front of the public. Hence the concept of responsive Web design. It has been more than ten years since the concept was put forward. CSS has also changed dramatically over the past decade, adding many new features, especially in the past two years (see CSS 2022 for more details). These changes are also significant for the development of responsive Web design. Una Kravets (@UNA), the great god, shared at Google I/O 2021, proposes a new responsive: component-driven Web design. Web ecology is about to enter a new era of responsive Web design, transforming the way we think about what it means and bringing new changes to Web design. Component-driven Web design (or development) is also known as the next generation of responsive Web design (or development). If you’re interested in this topic, read on.

The evolution of responsive Web design

Since we’re talking about responsive Web design, let’s take a moment and a brief look at how it’s evolved.

It’s no secret that from the time Tim Berners-Lee created the first Web page (circa August 1991) until the late 1990s, Web pages were pretty rudimentary:

It wasn’t until the late ’90s and early’ 20s that Web design and user experience slowly became aesthetic with the advent of CSS, and Web pages began to look like the websites we use today:

As you can see, the Web UI gets richer and prettier over time. This also forces Web developers to spend more time on layout, design, and typography. Although Web developers spend a lot of time on Web layout, many different layout methods have accumulated in the process. In the early days, Web developers mainly used fixed width and streaming layout to achieve the layout of Web pages. Streaming layouts, in particular, have been a sensation since Glenn Davis proposed and popularized them, and have long been considered responsive Web layouts.

Liquid Layout allows you to resize your Web page to suit different display resolutions or browser window sizes.

Consider a simple example of a streaming layout:

Demo

But streaming layouts are not perfect. On a Web page with a streaming layout, content might overflow, text might wrap on a smaller screen, and there might be a lot of unnecessary white space on a larger screen.

Most fluid layouts look fine at 800px x 600px to 1280px wide or larger screen resolutions. However, it would be better if we could break it down into smaller pieces, such as customizable layouts for 800px to 1024px, 1024px to 1280px, and above 1280px. Also, different layouts can be customized for 640px to 800px, 320px to 640px, 240px to 320px, and below 240px.

Around 2004, Cameron Adams (@TheManinBlue) in his blog Resolution Dependent Layout proposed dynamically building Web layouts based on screen Resolution, This means using JavaScript to load different CSS files based on the size of the browser window.

<! -- Narrow style sheet --> <link rel="alternate stylesheet" type="text/css" href="css/narrow.css" title="narrow"/> <! -- Default style sheet --> <link rel="stylesheet" type="text/css" href="css/normal.css" title="default"/> <! -- Wide style sheet --> <link rel="alternate stylesheet" type="text/css" href="css/wide.css" title="wide"/> <! -- Included JavaScript to switch style sheets --> <script src="scripts/dynamiclayout.js" type="text/javascript"></script>Copy the code

Note that on all tags the title property has the value narrow, default, and wide, and there is a dynamicLayout () function in dynamicLayout.js, Different stylesheets will be invoked based on the value of the title attribute of the tag:

function dynamicLayout(){ var browserWidth = getBrowserWidth(); // Narrow CSS rules if (browserWidth < 640){ changeLayout("narrow"); } // Normal (default) CSS rules if ((browserWidth >= 640) && (browserWidth <= 960)){ changeLayout("default"); } // Wide CSS rules if (browserWidth > 960){ changeLayout("wide"); }}Copy the code

Dynamic Resolution Dependent Layouts by @Kevin Hale explains this technique in detail.

This layout technique became known as resolution-dependent layout, after the title of a Cameron Adams blog post. This layout technique was popular before CSS media queries became popular, although it added extra work to developers who needed to provide different stylesheets for different custom layouts. It is also known as the early CSS media query (query breakpoints via JavaScript).

Although this scheme relies on dynamic resolution layout to provide better experience at different resolutions, with the launch of Opera Mini by Opera Software company on August 10, 2005 and the appearance of the first iPhone on January 9, 2007, different brands in the market, There are more mobile devices with different resolutions and brands’ own Web browsers.

In this environment, loading different stylesheets based on dynamic resolution is no longer practical, and Web developers have to come up with alternative solutions to accommodate different screen sizes. For a long time, and even today, to accommodate different screen sizes, a separate web site was created for the mobile end, that is, mobile subdomain sites. For example, the desktop and mobile versions of Facebook are accessed using two different domains:

As a result, developers have to work on two versions, which makes it more difficult, especially for Web applications that require rapid response and trial and error.

In 2010, Ethan Marcotte (@Beep) based his book A Dao of Web Design by John Allsopp (@JohnAllsopp), Responsive Web Design was proposed. Since then, Responsive Web Design (RWD) appeared in front of the public.

Ethan Marcotte (@Beep) mentioned in Responsive Web Design that the word “Responsive” originated from the field of architecture. It originally refers to the fact that the building itself will “respond” to the actual use situation and adjust itself. In Web development, “responsive” means that we develop Web pages that automatically adjust their layout “in response” to the size of the user’s device. As mentioned in this article, we can build a responsive Web site or Web application based on Fluid Grids, Flexible Images and Media Queries.

In addition, Ethan Marcotte (@Beep) built the first responsive Web page, arguably one of the classic examples of responsive Web design (unfortunately it doesn’t open anymore) :

So this example gives you an idea of what responsive Web design looks like. In fact, Ethan Marcotte mentioned in his article:

In the future, as the number of devices accessing the web increases, we’re not going to design for each device individually, but we’re going to design for each device as an aspect of that design.

In other words, the best user experience will be pursued on every device, and the design will automatically adapt to each device. In the past, designers knew exactly what their medium was, like an A4 piece of paper, a business card, or a poster. But in our multi-screen era, Web design must be designed with this in mind. We design for “any size.”

It has been more than a decade since Ethan Marcotte proposed the idea of responsive Web design and the implementation of different end-device screen resolution layouts based on different breakpoints (CSS media query instead of JavaScript query device screen resolution). Everyone says that every decade you see an ecosystem grow rapidly, and CSS is no different. Especially in the past two years, CSS has added many new features, such as the most anticipated container query feature @container, cascading layer @Layer, CSS scope @scope and so on.

As Una Kravets (@UNA) shared at Google I/O 2021:

With the advent of user preference queries, container queries, and other device types of queries (new features in CSS), the Web community is about to enter a new era of responsive Web design and change the way we think about what it means.

In other words, the next generation of responsive Web design is at hand, or is already upon us.

The state of responsive Web design

Before we talk about responsive Web design, let’s take a look at the current state of responsive Web design. Let’s look at the current state of responsive Web design from the perspectives of two different roles: Web designer and Web developer.

Let’s start with the role of a Web designer.

Today, even though mobile devices rule the world, Web designers still provide different designs for different devices when it comes to designing for different devices. For example, provide different designs for different device window sizes (e.g. mobile, tablet and desktop) :

Let’s take a look at the simplified design wireframes for different versions, as shown below:

In the figure above, the designer provides three different UI effects for the Card. Although the cards have different UI effects in different device Windows, they are composed of the same elements, including the card container, the card thumbnail, the card title and the card description:

As a Web designer, you’ve used multiple versions of the layout to show UI changes in three different states of the same component. Enough information for Web developers! At this point, the Web designer has provided the Web developer with a responsive Web design draft.

Next, take a look at the current state of responsive Web design from another role: Web developer. It is easy for Web developers to implement the card UI in the three states shown above. With the CSS media query feature, you can adjust the CSS style rules at different breakpoints:

/* Mobile First */ .card { display: flex; flex-wrap: wrap; gap: 10px; } /* Tablet */ @media (min-width: 700px) { .card { gap: 20px } } /* Laptop and Desktop */ @media (min-width: 1024px) { .card { position: relative } .card__thumb { position: absolute; inset: 0; }}Copy the code

This method can only be used when the same component exists in different versions independently. In order to satisfy this design, we need to add some additional class names to handle different UI effects for the cards in different states:

The CSS style code might look something like this:

/* Mobile First */ .card { display: flex; flex-wrap: wrap; gap: 10px; } /* Tablet */ @media (min-width: 700px) { .card--vertical { gap: 20px } } /* Laptop and Desktop */ @media (min-width: 1024px) { .card--featured { position: relative } .card--featured .card__thumb { position: absolute; inset: 0; }}Copy the code

This looks good, but the problem is that the component variants only work when the window width is greater than a certain value, such as 700px, when the.card–vertical card UI effect works; The. Card — Featured card UI effect only takes effect when the window width is greater than 1024px. In other words, if you want to see the. Card — Featured card effect on the tablet, you can’t see it because its media query doesn’t take effect until the width of the window is 1024px or larger.

Not only that, but the content of the Web is dynamic, and sometimes the output may not match the intended number of cards, in which case there will either be an empty space or cards will expand to fill the remaining (or available) space of the container. For example, in our example, on a window width of 700px or more, the. Card –vertical and. Card — Featured scenes are both possible.

For such scenarios, Web designers may prefer to have additional UI effects for cards. We’ll talk about that in the next video.

Simply put, the current responsive Web design is still the main scheme to use CSS media query features in different terminals to provide layout switch. While it satisfies most scenarios of Web page layout, it is relatively lacking in other capabilities, such as the ability to inject responsive styles into the components themselves. In other words, responsive Web pages built on window-width queries, and responsive components in particular, have limited capabilities.

Disadvantages of CSS media query

In the previous section we discussed how Web developers can use CSS media query features to query window widths (or other device features) to provide differentiated layouts for Web pages on different terminals. But it also revealed many deficiencies, even obvious ones. For example, the card component has three different UI effects that are dependent on the width of the browser window, which means that the card component cannot adjust its UI style to match the width of its parent container. This limits developers to using a particular style of a component only when the window width is greater than a certain value (breakpoint). For example, when the window width reaches 700px or more, the card component switches from the default. Card (horizontal) state to the. Card –vertical state. In other words, if we want to use the. Card –vertical card effect under the window width less than 700px, it will not work:

Another point is that when the server spit out a different amount of data than the designer intended, the final Web effect may not be what the designer intended. For example, if there is only one card, two, three, or more, and the design contains three, the Web development implementation might look something like this:

As shown in the figure above, if only one card is spit out, the width of the entire card will expand by the same as the width of the container (stretch). At this point, the width of the card is too wide, causing the thumbnail used on the card to be stretched, potentially blurring the thumbnail.

Actually? This is just wishful thinking on the part of the Web developer. The real intention of the designer might be something like this:

In this scenario, the CSS media query feature is tricky to implement, but the CSS container query feature is much easier to solve by querying the card parent container to determine how to display the card.

If summarized in one sentence:

Although Web developers can use global windowing information to style components, components still can’t have their own styles, and when we design systems based on components rather than pages, media queries can’t help!

Fortunately, the ecosystem is changing, and these two years have been particularly dramatic. For example, the container query feature that we’ve been waiting for has arrived. This problem can be easily solved if we switch the reactive style thinking of the component itself from the query window to query its ancestor container. In addition, earlier CSS media queries could only look up window widths and media features, but not user preferences for device Settings. However, CSS media query features have changed dramatically over the past two years. In addition to querying media (device) features, we can also query user preferences.

As Una Kravets puts it:

The Web ecosystem is once again taking CSS off the ground, and these new features will inject new power into responsive Web design. We are also about to enter a new era of responsive design and transform the way we think about what it means.

The next generation of responsive Web design

The term “Responsive Web Design” was coined by Ethan Marcotte in 2010 when media queries were applied to CSS. Since then, Web designers and developers have used responsive Web design methods to design and develop an immersive Web page or Web application for real-time adaptation to today’s seemingly bottomless end devices.

Today, when we talk about responsive Web design, Fluid Grids, Flexible Images and Media queries are the first things that come to mind in Ethan Marcotte’s (@Beep) Responsive Web Design blog post Queries) to build a Web page suitable for different screen sizes or different mobile terminal devices.

Web developers use CSS media queries to change the layout of entire pages and resize designs from top to bottom on mobile phones, tablets, and desktops. This works and works well, but it has the obvious drawback that the entire screen responds at once, or the entire page responds at once. While this responsiveness does have some significant impact on the user experience, it is not responsive to the needs of individual users and lacks responsive injection into the components themselves.

The good news is that ecosystems are changing, and they are changing very quickly. Web designers and engineers of Web platforms are beginning to build Web pages with a new kind of responsive technical approach known as component-driven Web Design.

Component-driven Web design

The responsive Web design approach we use today will soon be seen as outdated, just as we feel now as we transition from our original table-based HTML development in the ’90s.

The challenge Web designers now have to overcome is that the current responsive Web design approach is essentially a one-size-fits-all approach, treating the entire page and user experience as a whole, without any personalization.

Windows-based media queries (CSS media queries) give us a lot of media query capabilities, but lack the ability to provide sophistication to our Web design and create an experience that is unique to the user, their environment, and the actions they take on the page. We also lack the ability to inject reactive styles into the components themselves.

The components in question are elements on the Web that can be made up of collections or groups of other design elements. If we consider the component is made up of blocks, and apply the concept to such as slides, card or piece of content in the construction of common UI elements, will be easier to understand, in the near one day, we may take responsive design style into individual components or building blocks, to customize and adjust the user’s experience, Rather than applying a fixed set of styles and rules to the layout of the entire page.

We can use global window information to control styles such as the font size and maximum width of elements, or adjust the background image and layout of these components, but they still have no control over their own styles. This limitation is even more difficult when our responsive design systems are component-based rather than page-based.

The good news is that Web designers and developers around the world are working to change the ecosystem of responsive Web design. While fundamental design thought processes need to change in order to change the way we think about responsive design and how components fit into their surroundings, the way responsive design professionals approach responsive Web design is changing rapidly.

Fueling the innovation fire is the rapid growth of CSS and flexible layouts, such as the addition of new query rules, Flexbox and Grid layouts. The advances being made here are rapidly ushering in a new era of responsive Web design just beyond the horizon.

The RAPID evolution of the CSS ecosystem is about to revolutionize the concept of responsive Web design!

Now, more than a decade after we were introduced to the radical new concept of responsive Web design, we are once again witnessing the evolution of the responsive design ecosystem, where CSS adds features that are directly based on components rather than page-injection style responsiveness. This capability is called component-driven Web Design, and component-driven development is going to become a really popular development pattern.

To understand this shift in development patterns and prepare for the wave of change to come, let’s look at the changes we can expect in the responsive Web design movement and how this might change our concept of responsive design.

Respond to user needs

You may be familiar with media queries based on viewable area (via min-width, max-width, min-height, max-height, orientation, aspect-ratio, etc.), such as:

} @media (min-width: 45rem) {/* @media (min-width: 45rem) {/* @media (min-width: 45rem) {/* @media (min-width: 45rem) {/* @media (min-width: 45rem) {/* @media (min-width: 45rem) {/* @media (min-width: 45rem) {Copy the code

This is just the most basic part of the @media rules of CSS. In fact, @media rules contain about 24 features that can be queried, and about 19 of them are well supported. For details, see The article “Graphical CSS: CSS Media Queries”. Among these new query features are improvements to the user experience, such as part 11 of the Media Queries Level 5 specification, which allows you to design the Web experience according to your users’ specific preferences and needs.

It also means that these new media query features allow you to tailor the user’s experience to their preferences.

Many devices now offer some preferences. On a Mac, for example, there are a few Settings that users can make to suit their preferences:

CSS media queries provide user preference query features that identify user preferences on the system and help Web developers build more robust and personalized Web experiences, especially for users with accessibility requirements.

prefers-reduced-motion

A Web page or application is inevitably decorated with motion effects, but some users don’t like these animations, and for a few, they can make them physically uncomfortable. That’s why most devices now support a way for users to customize their Settings to their liking.

An ASIS-reduced-motion media query is used to detect whether the user’s system has animation reduction enabled. This example, for example, will show a set of annoying animations, but when you turn on the system’s “Reduce Motion” you will see the animation fade out.

.pulse { animation: pulse 2s infinite; } @media screen and (prefers-reduced-motion: reduce) { .pulse { animation: none; }}Copy the code

This is an example of how an animation can be stopped by an ASis-reduced-motion media feature. In fact, the TRANSITION from CSS can also be used for animations, and not all devices have a good performance support for animations (after all, animations are performance-expensive). We can write CSS like this:

@media screen and (cana-reduced-motion: reduce), (update: slow) {* {animation-duration: 0.001ms! important; animation-iteration-count: 1 ! important; The transition - duration: 0.001 ms! important; }}Copy the code

This code forces all animations that use animation duration or transition duration declarations to end at a speed that is imperceptible to the human eye. It works when users demand a less animated experience, or when the screen refresh rate of a device, such as a cheap smartphone, is low.

In addition, Eric Bailey, in his article Revisiting Reduced-Motion, The Reduced Motion Media Query, offers an idea:

“Not every device that has access to the network can animate, or animate smoothly.”

For devices with low refresh rates, this can lead to animation problems, such as animation stuttering. In that case, deleting the animation might be a better option. We can use aspis-reduced-motion and Update together:

@media screen and (cana-reduced-motion: reduce), (update: slow) {* {animation-duration: 0.001ms! important; animation-iteration-count: 1 ! important; The transition - duration: 0.001 ms! important; }}Copy the code

This code forces all animations that use animation-duration or transition-duration declarations to end at a speed imperceptible to the human eye. It works when a person requests a less dynamic experience, or when the device has a screen with a lower refresh rate, like e-ink or a cheap smartphone.

It is important to note, however, that the use of dynamic attenuation does not mean “no dynamic effects,” because dynamic effects can play a crucial role in conveying information on a Web page. Instead, guide these users with a solid, non-essential dynamic base experience, while gradually enhancing the experience of others who don’t have this preference.

If you’re interested in techniques for attenuating motor effects, you can also read:

• Revisiting prefers-reduced-motion, the reduced motion media query
• Meeting “2.2.2 Pause, Stop, Hide” with prefers-reduced-motion
• Respecting the Users’ Motion Preferences
• Designing With Reduced Motion For Motion Sensitivities
• Accessible Web Animation: The WCAG on Animation Explained
• Accessible Animations in React

prefers-color-scheme

As you probably know, after macOS and iOS13, apple devices have a Dark Mode effect, which means users can choose the colors provided by the system according to their preferences:

Using the PREFERn-color-scheme query feature allows you to respond to whether the user has Dark Mode on the device. In other words, it only takes a few lines of code to add Dark Mode to a Web page or application. First of all, we load the theme of light colors by default. We can declare the required color of light colors in :root, for example:

:root {
    --text-color: #444;
    --background-color: #f4f4f4;
}
Copy the code

And then through the media query prefers – color – scheme: dark to darker colors needed to reset the color:

@media screen and (bana-color-scheme: dark) {:root {-- color: Rgba (255,255,255,.8); --background-color: #121212; }}Copy the code

They can also be used together with theme-color and color-scheme when customizing different themes. This will control the theme color of the system application (e.g. browser) :

The color scheme the CSS properties and < meta > the name of the theme – color is the same. Both are designed to make it easier for developers to control the theme of a Web application or page based on user preferences, by allowing developers to add specific theme styles based on user preferences. The color-scheme attribute and the corresponding
tag interact with the PREFERence-color-scheme and work better together. The most important point is that color-scheme completely determines the default appearance, while fara-color-scheme determines the styliable appearance.

Suppose you have a simple page like this:

<head>
    <meta name="color-scheme" content="dark light">
    <style>
        fieldset {
            background-color: gainsboro;
        }
        @media (prefers-color-scheme: dark) {
            fieldset {
                background-color: darkslategray;
            }
        }
    </style>
    </head>
    <body>
        <p>
            Lorem ipsum dolor sit amet, legere ancillae ne vis.
        </p>
        <form>
            <fieldset>
                <legend>Lorem ipsum</legend>
                <button type="button">Lorem ipsum</button>
            </fieldset>
        </form>
</body>
Copy the code

The CSS code in

With a
metadata setting, the page tells the browser that it supports dark and light themes, and that dark themes are preferred.

Depending on whether the operating system is set to dark or light mode, the entire page appears light on dark and vice versa, based on the user agent style sheet. Developers do not provide additional CSS to change paragraph text or page background color.

Notice how the background color of the < Fieldset > element changes depending on whether dark mode is enabled, following the rules of the inline style sheet provided by the developer on the page. It’s either Gainsboro or DarkslateGray.

Above is the style specified by the developer and user agent in Light mode. According to the user agent’s style sheet, the text is black and the background is white. The background color of the

element is gainsboro, the color specified by the developer in the inline table.

Above is the style specified by the developer and user agent in dark mode. According to the user agent’s style sheet, the text is white and the background is black. The background color of the

element is DarkslateGray, the color specified by the developer in the inline style sheet.

The appearance of the button element is controlled by the user agent style sheet. Its color is set to the ButtonText system color, and its background and border colors are set to the ButtonFace system color.

Now notice how the border color of the element changes. Border-top-color and border-bottom-color values are changed from rgba(0,0,0,.847) (black) to rgba(255, 255, 255,.847) (white), Because the user agent updates ButtonFace dynamically based on the color scheme. The same applies to the color attribute of the element, which is set to the corresponding system color ButtonText.

That looks good, but it also leads to another new concept, system color.

The system color is not explained in detail here, if you are interested, you can read:

• Things like system preferences
• Windows High Contrast Mode, Forced Colors Mode And CSS Custom Properties
• Styling for Windows high contrast with new standards for forced colors
• Operating System and Browser Accessibility Display Modes

prefers-reduced-data

Not everyone is lucky enough to have a fast, reliable or unlimited data (data) plan.

You may have traveled for business, or you may have run out of data on your phone, and it’s not a good idea to visit a graphic-heavy site (although traffic isn’t a big deal these days, you can always pay for it). But once Rapa-reduced-data is supported, the headache can be avoided and users can save money. This feature allows users to skip large or high-resolution images.

.image { background-image: url("images/heavy.jpg"); } @media (prefers-reduced-data: reduce) { .image { background-image: url("images/light.avif"); }}Copy the code

When the user turns on “Low Data Mode” on the device, the light. Avif image will be loaded with lower traffic, which can help iPhone applications reduce network Data usage:

As an aside, the three media query features mentioned above are primarily used in CSS, but they can also be used in conjunction with thetag element of the HTML element. Different image sources can be selected according to the user’s device preferences:

<! <picture> <source srcset="dark.png" media="(PICTURE) dark)"> <source srcset="light.png" media="(prefers-color-scheme: light)"> <img src="light.png" alt="" /> </picture> <! > <picture> <source srcset="animation.jpg" media=" reduce)"> </source> <img srcset="animation.gif" alt="" /> </picture> <! > <picture> <source srcset="light.jpg" media=" reduce)" /> <img src="heavy.jpg" alt="" srcset="[email protected] 2x" /> </picture>Copy the code

prefers-contrast

The PREFERence-CONTRAST media query is mainly used to detect whether users ask the system to increase or decrease the contrast between adjacent colors. For example, some users who like reading e-books will encounter difficulties in reading text with a small contrast between the background and the text. They prefer a larger contrast, which is convenient for reading.

For example, here’s an example:

.contrast { background-color: #0958d8; color: #fff; } @media (prefers-contrast: high) { .contrast { background-color: #0a0db7; }}Copy the code

Other media features related to user preferences

As you can see from the W3C specification, the specification provides six media query features with respect to user preferences:

Media Feature Name	Media characteristic value	Whether to acceptminormaxvalue	describe
prefers-reduced-transparency	no-preference.reduce	✗	Whether users tend to opt for less transparency
forced-colors	active.none	✗	Check whether the user agent is restricting the palette
light-level	dim.normal.washed	✗	Ambient brightness

Here’s an example of formed-colors from Eric’s “Windows High Contrast Mode, Forced Colors Mode And CSS Custom Properties” :

Demo

Extract sample code using formed-colors:

// SCSS .c-dialog__content { background-color: var(--dialog-color-background); box-shadow: 0 1rem 2rem 0 #00000099; outline: var(--dialog-border-width) solid var(--dialog-border-color); padding: var(--dialog-padding-outer); width: min(90vw, 38rem); z-index: 1; @media (forced-colors: active) { --dialog-border-width: var(--size-300); }}Copy the code

Redefined the –dialog-border-width value in the formed-Colors media query feature. The reason for this is a very interesting adjustment. It turns the thin outline into a thick one. This adjustment helps show the outer boundaries of the modal box and conveys that it floats above the rest of the page. Forced color mode removes the box-shadow of the modal box, so we can’t rely on this visual effect in this dedicated browsing mode:

If you’re interested in any of the media query features mentioned above, read the following articles:

• Media features
• New CSS media query feature
• Things like system preferences
• Graphic CSS: CSS media query

Respond to the container’s requirements

CSS media queries have led to a revolution in responsive design, giving developers a way to query various aspects of the user agent or device environment, such as window size or user preferences, to change the style of a Web page. Until now, media queries have not been able to change the style of an element based on the size of the nearest container. Hence the container query you’ve been waiting for.

It’s hard to imagine how the shift from page-based responsive design (media queries) to container-based responsive design (container queries) will play a role in the evolution of the design ecosystem.

In order to answer this question, next we are divided into several aspects to introduce, hoping to give you some thinking, so as to get the answer you want.

The history of container queries

As I mentioned in CSS 2022. CSS container queries have long been a desirable feature, and have been ranked number one in CSS development reports over the years:

Since the design concept of responsive Web Design (RWD) was first proposed by @Ethan Marcotte in 2010, Web design has entered the era of modern Web layout. Developers can customize the presentation of Web pages based on CSS media query features (usually window width, media device features, etc.), such as different layouts, different font sizes, and different images based on the device characteristics of the user viewing content.

But for a Web designer or Web developer, there is still a missing feature in modern Web design or layout that the design of a page cannot respond to the width of its container (or any other feature). That said, it would be nice if Web developers could change the UI style based on the container width. Container queries will greatly help Web developers do their jobs better, and their omission (the absence of the container query feature) is a huge limitation when developing component-based code for the Web.

As a result, there is no end to the discussion about the features of container queries in the community.

Back in late 2019, when @Zach Leatherman was looking for the origins of container queries, one of the earliest solutions he found for container queries was @Andy Hume’s JavaScript based selector queries and reactive containers solution.

In 2015, @Mat ‘Wilto’ Marquis introduced the element to the world of responsive Web design in the Container Queries: Once More Unto the Breach Outlines the challenges of element queries and uses cases to demonstrate the features of container queries.

Then, in 2017, @Ethan Marcotte wrote an article about container queries and offered this observation:

In the years since his initial article focused on responsive Web design, Web designers and developers have increasingly focused their work on components rather than entire pages, making media queries less than ideal.

Since then, container queries have moved forward at a less than ideal pace, despite many advocates of media queries. Thoughts on an Implementable Path Forward for Container Queries @L. David Baron gives a concise explanation of the problem with Container Queries moving forward slowly.

Container queries require styles that depend on the size of the component, but given how CSS works, styles in a component affect its size. Breaking this cycle arbitrarily can produce strange results, interfere with the browser’s work, and increase the cost of browser optimization.

In addition to @David Baron, in June 2018, Greg Whitworth’s Over the Moon for Container Queries, a theme shared at CSS Day + UX Special in Amsterdam, Netherlands, also explains why container queries are slow to take off on the Web. More importantly, @Greg Whitworth also provides the ability to implement container queries using new JavaScript apis and CSS technologies. @David Barrrron also came up with a strategy to avoid this dilemma, and more importantly @Miriam Suzanne came up with the @Container method based on @David Baron’s strategy.

The @container method is implemented by applying size and layout restrictions to the elements being queried. Any element with size and layout restrictions can be queried through a new @container rule with syntax similar to existing media queries.

This proposal has been adopted by the W3C CSS Working Group and has been added to the CSS Containment Module Level 3 Module. Questions about this feature and progress of each grid platform can be found here.

Although CSS Containment Module Level 3 is TR, it does not mean that the specification is the final version. As of this writing, the syntax rules are still changing, so it is possible that the syntax shown in this article may change and the related examples may one day be invalid:

What is a container query

The biggest features of CSS container query are:

Container queries allow developers to define any element as a containment context. The descendants of the query container can change their style depending on the size of the query container or the calculation style.

In other words, a query container is created by specifying the type of query to be able using the container type attribute (container-type or container). Style rules that apply to descendants can be conditioned by querying them using the @Container conditional group rule.

Container queries provide a more dynamic approach to reactive design. This means that if you place the card component in a sidebar or in a grid inside the body of the page, the component itself displays information in a responsive manner based on the container rather than the viewport.

First, place the card into a container element, such as.card__container:

<! -- HTML --> <div class="card__container"> <div class="card"> <img src="https://picsum.photos/2568/600? random=1" width="2568" height="600" alt="" class="card__thumbnail" /> <div class="card__badge">Must Try</div> <h3 class="card__title">Best Brownies in Town</h3> <p class="card__describe">High quality ingredients and best in-class chef. Light, tender, and easy to make~</p> <button class="card__button">Order now</button> </div> </div>Copy the code

That is, when a card component is placed in a container, it is contained in that container, as in the code above. Card__container. This also means that we can use CSS container to query the width of.card__container and set different style rules for.card in @container. To achieve the real intention of the designer:

For example, the container width (.card__container) is set to different styles for.card when >400px, >550px, and >700px respectively:

The code might look like this:

/* Default */ .card { // ... } /* CSS Container Queries*/ .card__container { container-type: inline-size; } /* container's width > 400px*/ @container size(width > 400px) { .card { // ... } } /* container's width > 550px*/ @container size(width > 550px) { .card { // ... } } /* container's width > 700px*/ @container size(width > 700px) { .card { // ... }}Copy the code

Demo

Drag the slider in the lower right corner of the card to change the size of the.card__container container. You can see how the UI effect of the.card component changes:

The @Container rule, which works in a similar way to media queries using @Media, but instead of the UserAgent of the viewport and browser, @Container queries the parent container for information.

Use of container queries

The syntax for CSS container queries has been updated in several versions so far, with the latest use shown in the example above. The differences in how each version is used can be indexed in the following articles:

• Query the CSS container
• The changes container queries bring to the design
• In the container querycontainer 和 @container

Next, an example of a container query card will show you how to use CSS container query.

Define an inclusive context

To use the CSS container query feature, you first define a Containment Context. This is a bit like using Flexbox and Grid layouts (Flexbox or Grid contexts are defined using the display property), except instead of using the familiar display property to define an inclusive context, a new CSS property is used. The container.

Using container explicitly on an element tells the browser to query against the container and how to query for that particular container. For example, in the example shown above, we explicitly set the value of container-type to inline-size on the.card__container element (the parent of.card) :

.card__container {
    container-type: inline-size
}
Copy the code

The code above tells the browser to query based on the size change in the Inline Axis direction of the.card__container container. That is, when the.card__container width changes to a specified value, the styles of its descendants can be adjusted.

Container-type is a child of the container attribute. You can also name your container explicitly using container-name, which specifies a specific name for an inclusion context:

.card__container {
    container-name: card
}
Copy the code

This approach makes sense when you have multiple inclusion contexts in the same context, and you know more clearly which queries affect elements.

You can use the shorthand container property, but add the slash separator/between container-type and container-name:

.card__container { container-type: inline-size; container-name: card; } /* is equivalent to */. Card__container {container: inline-size/card; }Copy the code

If a container query is applied to an undefined element that contains an ancestor, the query will not be applied. That is, there is no default fallback inclusion context for either body or HTML elements. Also, define keywords that contain context names that cannot be CSS, such as Default, Inherit, initial, and so on.

Note:container-nameCan be omitted, if omitted its initial value will be usednone, butcontainer-typeCannot be omitted, if omitted, the inclusion context is not explicitly declared!

Define a container query

We now know that container (or its child attributes container-type and container-name) is used to explicitly declare the inclusion context (applying inclusion to an element) on an element.

Once you have this inclusion context, you can use CSS’s @rule @container to query inclusive elements, that is, containers. The @container rule is used similarly to @media and @supports:

@container containerName size(width > 45rem) {/* CSS that applies the descendants of the containment context */} @container size(width > 45rem) {/* CSS */} with inclusion context descendant elements appliedCopy the code

Both of these are correct usage gestures, and containerName in the first example refers to the name of the containment context explicitly declared by container-name. If the container name of the query is not specified in @container, the query will be queried against the element with the declared inclusion context closest to the style change. Such as:

@container size(width > 30em) { .card { border-radius: 20px; }}Copy the code

Indicates that the query will be queried against the most recent element with an explicit inclusion context declared for the.card element.

The size() function in this code is a new syntax for container queries. This is also one of the container query syntax changes that makes the query types more explicit. Because the specification has been improved to the point where queries can be made not only by size attributes, but also by style attributes.

As Terrible Mia shared on Twitter, styles can be queried using the style() function:

@container style(--card: large) {
    /* CSS Style */
}

@container size(width > 30em) and style(--card: large) {
    /* CSS Style */
}
Copy the code

As of this writing, no browser supports style queries. In addition, the query condition for @container (width > 30em) is equivalent to (min-width: 30em). Media Queries Level 4; @media Queries Level 4; @media Queries Level 4; Such as >=, <=, etc. to replace the previously obscure min- and Max – :

Container and @Container appear together in the above example code, but they do not refer to the same property. The former is a CSS property and the latter is a CSS code block. And there are essential differences:

• container 是 container-type 和 container-nameIs used to explicitly declare that an element is a query container and define the type of the query containercontainer-type) and the query container name (specified bycontainer-nameSpecified).
• @container(with@Rule), which is similar to conditional CSS@mediaor@supportsRule, is a condition group rule whose condition is a container query whose size (size) and/or styles (style) the Boolean combination of queries. Only if its condition is true (true),@containerAny style in the rule block will be applied by the user agent, otherwise it will be considered invalid and ignored by the user agent.

Container query card

I think you’ve got an idea of the theory and concepts of container queries. Next, let’s put these things together to see in detail how the container card example shown earlier is implemented.

Since the advent of responsive Web design and the proliferation of Mobile devices, there has been a mobile-first versus desktop-first debate in design:

If you’re interested in this discussion, read Ahmad Shadeed’s The State Of Mobile First and Desktop First.

Personally, it makes the most sense by far to look at container queries and consider a “mobile-first” design when developing “breakpoints” across component states. That is, make the narrowest view the default style, and then handle style updates with larger widths through container queries.

As shown in the figure above, we implement the UI effects at different state breakpoints of the card from left to right. Start with the narrowest card (leftmost, Default state). The HTML structure needed to build this card component is as follows:

<div class="card__container"> <div class="card"> <img src="https://picsum.photos/2568/600? random=1" width="2568" height="600" alt="" class="card__thumbnail" /> <h3 class="card__title">Container Queries Rule</h3> <p class="card__describe">Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque? </p> <button class="card__button">Order now</button> </div> </div>Copy the code

We use CSS Grid to complete the card layout. Starting with the narrowest, add the following CSS code:

.card { display: grid; gap: 1rem; margin: 5vh auto; Border - the radius: 0.5 rem; Box-shadow: 0 0.25rem 0.rem-0.15rem HSLA (0 0% 0% / 55%); background-color: #fff; } .card__thumbnail { max-width: 100%; aspect-ratio: 16 / 9; height: auto; object-fit: cover; Border-radius: 0.5rem 0.5rem 0 0; } .card__title { font-weight: 700; Font size: Clamp (1.2 REM, 1.2 REM + 3VW, 1.5rem); padding: 0 20px; white-space: nowrap; text-overflow: ellipsis; overflow: hidden; } .card__describe { color: #666; The line - height: 1.4; padding: 0 20px; display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 3; overflow: hidden; } .card__button { display: inline-flex; justify-content: center; align-items: center; border: none; border-radius: 10rem; background-color: #feca53; padding: 10px 20px; color: #000; text-decoration: none; box-shadow: 0 3px 8px rgb(0 0 0 / 7%); The transition: all 0.2 s linear; font-weight: 700; justify-self: end; margin: 0 20px 20px 0; cursor: pointer; } .card__button:hover { background-color: #ff9800; }Copy the code

As you can see in the effect above, the card components automatically change with the width of their.card__container, which looks fine in a narrow screen, but a little strange in a wider one. But don’t worry, this is just the beginning. What we expect is to change the layout of the card components at different breakpoints in the container through the feature of the container query. As described earlier, we need to create an inclusive context, using container on.card__container to explicitly declare that the element is an inclusive context.

.card__container {
    container: inline-size;
}
Copy the code

We can then adjust the layout at different breakpoints using CSS Grid layout related features, that is, adding different container queries to update the card component layout and style.

Card__container width > or equal to 400px */ @container size(width >= 400px) {. Card {grid-template-columns: 180px 1fr; grid-template-areas: "thumbnail title" "thumbnail describe" "thumbnail button"; gap: 10px 20px; align-items: start; } .card__thumbnail { grid-area: thumbnail; aspect-ratio: 1; Border-radius: 0.5rem 0 0 0.5rem; } .card__title { grid-area: title; padding-left: 0; margin-top: 16px; } .card__describe { grid-area: describe; padding-left: 0; -webkit-line-clamp: 2; } .card__button { grid-area: button; Card__container width = 550px */ @container size(width >= 550px) {. Card {grid-template-columns: 240px 1fr; grid-template-rows: 56px auto 60px; } .card__describe { -webkit-line-clamp: 3; Card__container width > or equal to 700px */ @container size(width >= 700px) {. Card {grid-template-areas: "thumbnail" "title" "describe"; grid-template-columns: auto; grid-template-rows: auto auto auto; gap: 1rem; } .card::before { content: ""; Background-color: RGB (0, 0); background-color: RGB (0, 0); Background-image: Linear-gradient (to top, RGB (0.0000/0.8), RGB (0.0000/0) 60%, RGB (0.0000/0.8) 100%); display: block; grid-row: 1 / -1; grid-column: 1 / -1; z-index: 2; min-height: 100%; aspect-ratio: 4 / 3; Border - the radius: 0.5 rem; } .card__thumbnail { grid-row: 1 / -1; aspect-ratio: 4 / 3; Border - the radius: 0.5 rem; z-index: 1; } .card__title { padding: 0 20px; z-index: 3; color: #fff; } .card__describe { -webkit-line-clamp: 2; padding: 0 20px; margin-bottom: 20px; z-index: 3; color: #ddd; } .card__button { display: none; }}Copy the code

The effect is as follows:

Demo

In the example above, try dragging the lower right corner of the card to change the width of the card container. You should see the following effect:

Once you have a card component like this, if you place it in a different location, even on the same page, under the same window breakpoint, it will automatically match the layout (or UI effect) that is most appropriate for the container breakpoint. Such as:

Demo

Try resize the window in the example above:

Media query vs. container query

From the examples above, I think you have a better idea of the container query feature. Container queries are very similar to media queries from a usage point of view, so one might ask, does container queries eliminate the need for media queries? Before we answer that question, let’s briefly look at the differences.

As we all know, media query queries have browser window widths (among other query features, of course), while container query queries the width (or style) of a component’s parent container, an ancestor element with an inclusive context. The following figure may clearly illustrate the difference between the two:

As far as I am concerned, the relationship between the two is not about who replaces who, but more about the coexistence of the two. With the advent of the container query feature, we can adjust the layout or UI style not only based on window breakpoints, but also based on container breakpoints. In other words, media query is a Macro Layout, which can be used for the overall page Layout. Container queries can adjust each element of a component, creating a Micro Layout.

What problem do container queries solve?

At the heart of the concept of responsive design, as we all know, is the advent of CSS media queries, which allow developers to set style rules based on the size of the browser window. As a result, responsive design and CSS media queries open up more Web layout solutions, as well as best practices built around responsive window sizes over the years. Moreover, design systems and component libraries have become more widespread in recent years. The bigger hope for more developers is:

Once built, anywhere deployed!

This also means that a separately developed Web component can work in any situation to make building complex interfaces more efficient and consistent. Instead, these components are grouped together to form a Web page or Web application interface. Currently, when only media queries are available, an additional layer is often required to coordinate the mutation of components that vary in size across Windows. In these cases, you may have to use more class names at more breakpoints to set different style rules. Even worse, even doing so often fails to achieve the optimal UI surface.

Most of the time, responsive Web design is not about browser window size but about container size, such as:

Fortunately, CSS container queries take us beyond the browser window size and allow any component or element to respond to a defined container size. So, while you may still use reactive layouts for Web pages, any component of a Web page can define its own style variations through container queries. It can then adjust its style depending on whether it is displayed in a narrow or wide container.

Container queries let us not only consider the browser window size, but allow any component or element to respond to the defined container size!

That is, with CSS container queries, you can define the entire style of a component in a very precise and predictable way.

Design with container queries in mind

While responsive design brings more accessibility to Web designers, it still has many limitations. What is more desirable for Web designers is the ability to provide different design styles depending on the component container size. Again, take the card component:

That is, with the advent of CSS container queries, as a Web designer, you need to design Web pages (or components) based on container size. In this way, details and variations of components can be provided to Web developers, who can code (develop) based on those details.

However, this does not mean that responsive design has lost its meaning after the container query feature. In the future, container queries and responsive design will coexist, and simply put, Web designers may divide components into the following parts when designing them:

• Windows-based (CSS media Query)
• Container based (CSS container query)
• General-purpose (unaffected components)

Such as:

In the future, Web designers might present designs to Web developers that look something like this:

Perhaps because of the advent of container queries, designers will make adjustments when designing the Web. The design drafts that are fed to Web development may also differ from previous patterns. At this point, Web developers need to understand the designer’s intentions. For example, a Web designer might provide a card component design that looks like this in a future design:

As a Web developer, you need to change your understanding of the intent of the design diagram when you see it, and not continue to be obsessed with adjusting component UI based on window size.

The above is a windows-based development mode that requires different class names for the card component and the card component UI to be adjusted under the corresponding class name based on the window size. With container features, we can use modern Web layout techniques, such as Flexbox or Grid, to have the card component adjust its UI based on its container:

As shown above, you can change the size of the card container based on the window size using techniques such as CSS media query features, Flexbox, or Grid layout so that the card component responds to its container size. Card__container.

It’s very useful to have a component that responds to the size of its parent container (UI adjustments), as you can see, we can build a single component that fits the design needs of different window layouts!

Container queries should not complicate components

A component is a combination of many elements:

While the container query feature comes along to allow components to respond based on their container size, it is important to remember that there should be a degree of responsiveness. If you overdo it, it’s better for Web developers to build a completely new component from scratch, rather than using the container query feature to implement UI responses. In the case of the UserProfile component, the internal structure of the component remains the same, or at least no new structure is added, with minor adjustments, such as tweaking the layout to achieve a different UI effect, or switching internal elements to show and hide. In this scenario, the use of container query features is attractive:

Scoped style

To complement the container query feature, the CSS working group is also actively discussing Scoped Styles to help provide components with proper namespaces to avoid collisions.

Scoped styles allow passing and component-specific styles to avoid naming conflicts, and many frameworks and plug-ins (such as CSS modules) already allow us to do this within frameworks. This specification now allows us to write native-wrapped styles for components in readable CSS without adjusting the markup.

/* @scope (<root>#) [to (<boundary>#)]? {... } */ @scope (.tabs) to (.panel) { :scope { /* targeting the scope root */ } .light-theme :scope .tab { /* contextual styles */ } }Copy the code

I don’t know much about scoped styles myself, so I won’t go into too much detail here to avoid making too many mistakes.

Scoped styles can be passed to specific components through different namespace styles to avoid naming conflicts. Cascading layering (@layer), another expected feature of CSS like container queries, can also be used to solve naming and style conflicts. This feature is already supported by Safari and Chrome. If you are interested in this topic, you can read the article “Taking a Look at cascading layers of CSS (@Layer)”.

Respond to shape requirements

In addition to responding to user needs and container needs, the new generation of responsive Web design also has another response demand, that is, the response demand of appearance.

What is the shape response requirement?

Folding devices have been on the market for nearly three years, and you’ve probably already been exposed to some like the one below:

It can be roughly divided into two types: dual-screen foldable devices (such as Microsoft Surface Duo) and single-screen foldable devices (such as Huawei Mate XS) :

On multi-screen or foldable devices, the opening posture of Web applications or Web pages on these devices will also be different. Applications can be displayed on a single screen or across screens:

In other words, our application or page will need to be able to span the screen, respond to the span, and may need to be able to logically separate content.

It can be said that multi-screen or foldable devices open up more screen space and transport users to another world with unique poses. With this device, UI designers, user experience designers, and Web developers, in addition to users, are faced with unlocking unprecedented Web experiences. This will be one of the biggest changes in Web development in the last decade, and one of the biggest challenges developers will face.

Here we call the response to multiscreen and foldable devices the need to respond to shape. This is part of responsive Web design.

Because foldable devices are relatively new, many developers do not have enough knowledge or even know where to start when facing these new devices. Actually? Some Web developers are already working on apis for us, with the exception of Samsung’s @Diego Gonzalez, mentioned at the beginning of this article, Intel Corporation’s (INTC) @Kenneth Rohde Christiansen is joined by Microsoft’s (MSFT) @Bogdan Brinza, @Daniel Libby and @Zouhir Chahoud. However, for Web developers, these specifications (CSS-related features) and Web apis (JavaScript apis) are still relatively new, with a lot of uncertainty and even diversity.

So far there are two main parts. One section, Web API for Dual and Foldable Screens, was developed by Microsoft’s @Bogdan Brinza, @Daniel Libby, and @Zouhir Chahoud, and is more suitable for “sloped” foldable devices. The other part is the screen folding API, currently in the W3C specification ED stage, which is more suitable for “seamless” folding devices.

@argyleink started a discussion on Github about using CSS media features to detect folded screens. That is, Web developers can use @media-related features to identify folded screens and provide media queries for the types of folded screens (such as “slit” and “seamless”).

For example, screen-spanning features can be used to help Web developers detect whether the “root view” spans multiple adjacent display regions and provide detailed information about the configuration of those adjacent display regions.

You can also use screen-fold-posture and screen-fold-Angle media queries to query seamless devices:

Horizontal-viewport-segments and vertical-viewport-segments can also be used to query the number of viewports:

horizontal-viewport-segments 和 vertical-viewport-segmentsAre the two latest query features that will replace the originalscreen-spanningThis media query feature!

In addition, there are some folding positions to query:

In addition to CSS media queries, six new CSS environment variables have been introduced to help developers calculate the geometry of the display area and calculate the geometry of the hinge area obscured by physical features:

The six CSS environment variables shown above will replace the previous env(fold-top), ENV (fold-left), env(fold-width), and ENV (fold-height).

For Web developers, we can use it like this:

// @media (spanning: single-fold-vertical) {// CSS Code... } @media (screen-fold-posture: laptop){// CSS Code... } @media (max-screen-fold-angle: 120deg) {// CSS Code... } @media (horizontal-viewport-segments: 2) {// CSS Code... } @media (vertical-viewport-segments: 2) { // CSS Code... }Copy the code

In modern layouts, the combination of these media query features, CSS environment variables, and CSS Grid layouts can easily meet the changing needs of shape response. Such as:

:root {
    --sidebar-width: 5rem;
}

@media (spanning: single-fold-vertical) {
    :root {
        --sidebar-width: env(viewport-segment-left 0 0);
    }
}

main {
    display: grid;
    grid-template-columns: var(--sidebar-width) 1fr;
}
Copy the code

Stephanie provides an example in her latest post Building Web Layouts For Dual-Screen And Foldable Devices. Horizontal-viewport-segments (horizontal-viewport-segments: 2)

.recipe { display: grid; grid-template-columns: repeat(3, 1fr); grid-template-rows: minmax(175px, max-content); grid-gap: 1rem; } .recipe-meta { grid-column: 1 / 4; } img { grid-column: 1 / 4; } .recipe-details__ingredients { grid-row: 3; } .recipe-details__preparation { grid-column: 2 / 4; grid-row: 3; } @media (horizontal-viewport-segments: 2) { .recipe { grid-template-columns: env(viewport-segment-width 0 0) 1fr 1fr; grid-template-rows: repeat(2, 175px) minmax(175px, max-content); } .recipe-meta { grid-column: 1 / 2; } img { grid-column: 2 / 4; grid-row: 1 / 3; } .recipe-details__ingredients { grid-row: 2; } .recipe-details__preparation { grid-column: 2 / 4; grid-row: 3; }}Copy the code

The key code for the layout is captured from the sample above. The final effect is as follows:

If you’re interested in multi-screen or foldable technologies, you can also read:

• Talk about how Android foldscreens change interaction design and development
• The changes that the collapsible Web may bring to us
• A Web API that can be used for dual and folding screens
• Collapse-related Web API
• Foldable CSS and JavaScript update for web developers
• Building Web Layouts For Dual-Screen And Foldable Devices

Technological change is endless, and the user terminals we will face in the future will never be the only devices and media we can see today, just like VR (virtual reality) and AR (augmented reality) devices currently used in the game industry. While it’s rare to see VR and AR used in other industries right now, we can expect to see VR and AR just as we’ve seen touchscreen devices for decades, as VR and AR devices mature and more are released. There may come a time when you design (or develop) Web pages or applications that need to look good on VR and AR devices.

The image above is from UX Case Study: Metaverse Banking VR/AR Design Concept of the Future. UXDA’s team of professional financial USER experience architects and designers introduces you to the first mixed reality banking concepts, including VR and AR banking design, tablets, wearables, desktop and mobile banking UI/UX.

What I want to say here is that the future of responsive Web design will likely respond to richer and more complex shape requirements.

conclusion

Responsive Web design has brought the Web to every connected screen that people touch today. Web designers and creative developers are driving the evolution of design approaches with creative thinking, bold thinking and a certain audacity to explore, test and iterate on their ideas to make online experiences more engaging, accessible and intelligent. Think of component-driven Web design as mentioned here.

The advent of component-driven Web design, or CSS container queries, scoped styles, cascading layer controls and other advanced features, has given us the opportunity to isolate component styles from page layouts, global styles, and user styles for more resilient and responsive design. This means that you can now use page-based media queries to design macro layouts, including subtle differences between multiple or folded screens; At the same time, container-based query is used to design micro-layout of components, and media query based on user preference is added to achieve customized experience based on user’s unique preferences and needs.

This is the next generation of responsive Web design, or component-driven Web design (or development). It combines macro layout with micro layout and, most importantly, takes user customization and dimensions into account.

Any one of these changes would constitute a major shift in the way we design the Web. But together, they represent a huge shift in how we conceptualize even responsive design. It’s time to think about responsive design that goes beyond viewport size, and start thinking about all these new directions for better component-based and customizable experiences.

In other words. If we incorporate these component-driven capabilities into our design systems and change the way we approach Web design in general, we can leverage these capabilities and more to improve the user experience of every visitor to your site. We can provide them with a truly personalized experience that increases engagement and conversion rates, and ultimately increases user perception of your brand.

We’re no longer designing for the user base. Our understanding of the term “audience” will change as content and experiences become highly focused for the audience of one person rather than many.

Component-driven responsive Web design will make the Web truly portable and adaptable to devices that haven’t even been invented yet. Instead of playing catch-up and designing within today’s technology, we will only design for the user.

Finally, I hope the concepts and techniques mentioned in this article have been helpful to you.