- Mobile-first CSS
- Desktop-first CSS
- Mobile-first advantages
- Development hierarchy
- Tried and tested
- Prioritizes the mobile view
- Prevents desktop-centric development
- Mobile-first disadvantages
- Increased complexity
- Higher CSS specificity
- Requires more regression testing
- The browser is unable to prioritize CSS downloads
- The property value overrides problem
- Closed media query ranges in practice
- Bundling versus separating the CSS
- Which HTTP version are you using?
- Splitting the CSS
- Moving On
The use of mobile devices has become widespread the world over. It has presented tremendous opportunities for businesses to market their brand and showcase their products. So, they want their website to provide the best experience to mobile users. That is why they assign the responsibility to build a custom mobile-friendly website to an expert website development firm.
Usually, specialists of website development agencies follow one of the following approaches for building websites for mobile users.
Mobile-first CSS
In this approach, developers start writing the CSS for smaller viewport sizes. A viewport is the web page area the user can see. Then, they use CSS media queries to alter the experience for larger devices such as tablets or desktops.
Desktop-first CSS
The desktop-first CSS is also known as non-mobile-first CSS. In this approach, the CSS is initially written for the desktop view. Then, the media query is used for overwriting the existing CSS to fit the decreasing viewport width.
Here is something important for businesses and developers who want to choose the mobile-first approach for building websites. So, pay attention.
Your perception of the mobile-first design methodology is that it is excellent. Because it focuses on providing what matters to mobile users: providing them the best experience. It is well-practiced and has been a commonly used design pattern for years. So you may believe that building your CSS mobile-first website should also be great. Well, only sometimes. We will tell you the reason why it will only work sometimes.
Classic mobile-first CSS development involves the principle of overwriting style declarations. Here, the developers begin their CSS with default style declarations. Then, they overwrite and add new styles and breakpoints with min-width media queries for larger viewports. But all these exceptions create complexity and inefficiency. It, in turn, can increase the testing effort and make the code base harder to maintain. Developers certainly want to avoid such situations.
The mobile-first development CSS is the best tool in our company’s mobile website development projects till now. However, it may not be the best and ideal tool for all projects or situations. So, you need to evaluate its appropriateness for the visual design and user interactions you build in a website.
To help you get started in mobile-friendly website development, we are discussing here various factors tackled by us. It would be best if you watch for the factors mentioned below. Also, we have discussed here some alternative solutions if CSS for mobile first is not the right fit approach for your project.
Let us first discuss the advantages and disadvantages of the mobile-first approach.
Mobile-first advantages
There are some things worth liking with mobile-first CSS development. Due to them, mobile-first CSS development was able to become the de facto development methodology for so long.
Development hierarchy
The mobile-first approach provides a nice development hierarchy. So, your developers can focus on the mobile view of the website and keep developing the website.
Tried and tested
It is a tried and tested methodology that has worked for years. The reason for this is it solves a problem well
Prioritizes the mobile view
The mobile view is the simplest. Arguably, it is also the most important due to these reasons. It encompasses all key user journeys and is often responsible for a higher proportion of user visits depending on the project.
Prevents desktop-centric development
It can be tempting to focus first on the desktop view as development is done using desktop computers. But focusing on mobile from the start prevents us from getting stuck later. Imagine a scenario where your developers must spend time retrofitting a desktop-centric site to work on mobile devices. They certainly will want to avoid this situation.
Mobile-first disadvantages
The mobile-first approach is not only about advantages. There are some disadvantages as well. Setting style declarations and then overwriting them at higher breakpoints can lead to undesirable outcomes.
Increased complexity
The further you go up in the breakpoint hierarchy, the more unnecessary code you inherit from lower breakpoints.
Higher CSS specificity
Styles that have reverted to their browser default value in a class name declaration now have a higher specificity. (Specificity is the algorithm that browsers use for determining the CSS declaration that is the most relevant to an element. It determines the property value to apply to the element.)
Higher specificity can be a headache on large projects where you want to keep the CSS selectors as simple as possible.
Requires more regression testing
The changes made to the CSS at a lower view (such as adding a new style) require regression testing of all higher breakpoints. (Regression testing is software testing performed after a code update. It helps to ensure that the update has introduced no bugs in the code).
The browser is unable to prioritize CSS downloads
At wider breakpoints, classic min-width mobile-first CSS media queries do not leverage the browser’s capability to download CSS files in priority order.
The property value overrides problem
There is nothing intrinsically wrong with overwriting values. CSS was designed to perform precisely this. Still, inheriting incorrect values does not help and leads to burden and inefficiency. Moreover, it can lead to increased style specificity where your developers have to overwrite styles to reset them back to their defaults. It may cause issues later, especially when the developers use a combination of bespoke CSS and utility classes. They cannot use a utility class for a style reset with a higher specificity.
Keeping this in mind, we are developing CSS these days by focusing much more on the default values. There is no specific order and no chains of specific values to track. As a result, we are left free to develop breakpoints simultaneously. We concentrate on finding common styles and isolating the specific exceptions in closed media query ranges. They include any range with a max-width set.
This approach brings up some opportunities as we can look at each breakpoint as a clean slate. If a component’s layout appears like it should be based on Flexbox at all breakpoints, it is fine. Also, the layout can be coded in the default style sheet. (The Flexbox, also known as the flexible box model, in CSS is a one-dimensional layout model. It has efficient and flexible layouts with distributed spaces among items to control their alignment structure. This layout model provides a clean and easy way to arrange items within a container.)
There may be a situation where you may feel that the Grid layout is much better for the large screens and Flexbox layout is much better for mobile screens. These both can be done entirely independently when the CSS is put into closed media query ranges. Also, for simultaneous development, you need to have a good understanding of any given component in all breakpoints in advance. It can help to identify the surfacing of issues in the design earlier in the development process. We don’t want to get stuck in a difficult situation. Here, we build a complex component for mobile. Then, we build the designs for the desktop and find they are equally complex and incompatible with the HTML we have created for the mobile view.
Though this approach is only the right fit for some, we encourage you to try it. Various tools can help you with concurrent development.
Having said that, we don’t feel the order itself is particularly relevant. Are you comfortable with focusing on the mobile view? Moreover, do you have a good understanding of the requirements for other breakpoints? Do you also prefer to work on one device at a time?
Then, by all means, follow the classic development order. The important thing is identifying common exceptions and styles, so you can put them in the relevant stylesheet. We find this a little easier when working on a component across breakpoints, but this is not a requirement.
Closed media query ranges in practice
When working with classic mobile-first CSS, we overwrite the styles. But we can avoid this with the use of media query ranges. To explain the difference, let us presume there are three visual designs. (Here, we use SCSS (Sassy Cascading Style Sheets) for brevity. SCSS basically is a more advanced and evolved variant of the CSS language.)
I. smaller than 768
II. from 768 to below 1024
III. 1024 and anything larger
Let us take a simple example where a block-level element has a default padding of 20px. It is overwritten to be 40px on the tablet and set back to 20px on the desktop.
| Classic min-width mobile-first | Closed media query range |
| .my-block {
padding: 20px;
@media (min-width: 768px) { padding: 40 px; } @media (min-width: 1024px) { padding: 20px; } } | my-block { padding: 20px; @media (min-width: 768px) and (max-width: 1023.98px) { padding: 40px; } } |
The subtle difference is the mobile-first example sets the default padding to 20px. Then, it overwrites the padding at each breakpoint, setting it three times. Compared to the first, the second example sets the default padding to 20px. Then, it overrides the padding only at the relevant breakpoint, where it is not the default value. (Tablet is the exception in this instance).
The goal here is to:
I. Only set styles when they are needed.
II. Not setting styles with the exception of overwriting them later on, again and again.
Closed media query ranges provide us with the best way to achieve this. To bring a change to any given view, we make it in the CSS media query range applicable to the specific breakpoint. We will be much less likely to introduce unwanted alterations. Plus, our regression testing only requires focusing on the breakpoint we have edited.
By considering the above example, we may find that .my-block spacing on the desktop is already accounted for by the margin at that breakpoint. Also, as we want to remove the padding altogether, we can do this by setting the mobile padding in a closed media query range.
.my-block {
@media (max-wdith: 767.98px) {
padding: 20px;
}
@media (min-width: 768px) and (max-width: 1023.98px) {
padding: 40px;
}
}
@media (max-wdith: 767.98px) {
padding: 20px;
}
@media (min-width: 768px) and (max-width: 1023.98px) {
padding: 40px;
}
}
The browser default padding of our block is 0. So, we will not add a desktop media query and use unset or 0 for the padding value (we will need this value with mobile-first). Instead, we can wrap the mobile padding in a closed media query (since it is now also an exception). So it will not get picked up at wider breakpoints. At the desktop breakpoint, we will not need to set any padding style because we want the browser’s default value.
Bundling versus separating the CSS
In the past, keeping the number of requests to a minimum was extremely important. It was due to the browser’s limit of concurrent requests (typically around 6). Consequently, the use of image sprites and CSS bundling was the norm. It involved all the CSS downloading in one go, as one stylesheet with the highest priority.
Now HTTP/2 and HTTP/3 are available. So, the number of requests is no longer the big deal as it used to be in the past. It lets us separate the CSS into multiple files with media query. The clear benefit is that the browser can now request the higher priority CSS it currently requires than the CSS it doesn’t need. It has a higher level of performance and can lessen the overall time page rendering is blocked.
Which HTTP version are you using?
To find out which HTTP version you are using, go to your website and open your browser’s dev tools. Then, select the Network tab and make sure the Protocol column is seen. If h2 is listed under Protocol, it indicates that HTTP/2 is being used.
If your website still uses HTTP/1, it is time to make way for HTTP/2. Excellent user support is available for HTTP/2.
Splitting the CSS
Separating the CSS into individual files is a useful task. Linking the separate CSS files through the relevant media attribute allows the browser to identify the immediately needed files (because they are render-blocking). It also allows the browser to identify the files that can be deferred. Based on this, it allocates an appropriate priority to each file.
Here is an example of a website visited on a mobile breakpoint. We see here that the mobile and default CSS are loaded with the highest priority as they are currently required to render the page. The remaining CSS files (print, tablet, and desktop) are still downloaded but with the lowest priority. The remaining files are downloaded as they may be required later.
For Note 1 related to the above table, see the end of the article:
With bundled CSS, the browser downloads and parses the CSS file before rendering can start.
It is noted that the CSS is separated into different files linked and marked up with the relevant media attribute. So the browser can prioritize the files it currently needs. Using closed media query ranges lets the browser do this at all widths. But in classic mobile-first min-width queries, the desktop browser has to download all the CSS with the Highest priority. We can’t presume that desktop users always have a fast connection. For example, internet connection speeds are still slow in many rural areas.
Based on project requirements, the media queries and the number of separate CSS files will vary from one project to another. But they may look similar to this example.
As per the project’s deployment strategy, a change to one file (for example, mobile.css) only requires the QA team to perform regression testing on devices in that particular media query range. Compare this to the prospect of deploying the single bundled site.css file, an approach that will normally trigger a full regression test.
Moving On
The uptake of mobile-first CSS was a really key milestone in web development. Because it has helped front-end developers focus on mobile web applications instead of developing sites on the desktop and then trying to retrofit them to work on other devices.
We don’t think anyone wants to return to that development model again. But we mustn’t lose sight of the issue it highlighted: things can easily get extremely complex and less efficient if we prioritize one specific device-any device-over others. For this reason, while focusing on the CSS in its own right, we have to be always aware of what is the default setting and what is an exception. It seems like the natural next step. We are beginning to notice small simplifications in our CSS as well as the CSS created by other developers. Furthermore, we have started observing that testing and maintenance work is also a bit more simplified and productive
In general, simplifying the creation of CSS rules whenever we can is a cleaner approach than the one involving circles of overrides. But whichever methodology you choose, it needs to suit your project. Mobile-first may be the best choice for what is involved, or it may not turn out to be the best choice. But first, you need to have a solid understanding of the trade-offs you are stepping into.
Notwithstanding the disadvantages and limitations of mobile-first CSS, it is still the most preferred methodology for development professionals. With the mobile-first CSS best practices mentioned above, you can code your website even more cleanly and efficiently. Also, you can reduce your development time, improve productivity, and get the best results. Finally, Vcana Global development professionals can confidently say that the use of mobile-first CSS is going to stay here and become more widespread in the future.
