The mobile-first approach to design is great — it focuses on what’s really important to the user, it’s well practiced, and it’s been a common design pattern for years. So developing your CSS mobile-first should be great too… right?
Well, not necessarily. Classic mobile-first CSS development is based on the principle of overriding style declarations: you start your CSS with a default style declaration and overwrite and/or add new styles as you add breakpoints, use minimum-width media queries for larger viewports (For a good overview see “What is mobile-first CSS and why is it so popular?”). But all of these exceptions create complexity and inefficiency, which in turn lead to increased testing effort and a more difficult codebase to maintain. Admit it – how many of us would like to do that?
In your own projects, mobile-first CSS is probably the best tool for the job, but first you need to evaluate its suitability based on the visual design and user interaction you’re dealing with. To help you get started, here’s my approach to the factors you need to be aware of, and if mobile-first doesn’t seem right for your project, I’ll discuss some alternative solutions.
The mobile-first advantage
Some of the advantages of mobile-first CSS development – and why it’s been the de facto development method for so long – make sense:
development level. Without a doubt, one of the things you get out of mobile first is a great development hierarchy – you just focus on the mobile view and start developing.
Try and test. This is a tried and true method that has worked for years: it solves the problem very well.
Prioritize mobile views. The mobile view is the simplest, and arguably the most important, as it encompasses all the key user journeys and usually accounts for a higher percentage of user visits (depending on the item).
Prevent desktop-centric development. Since development is done using a desktop computer, it may be tempting to initially focus on the desktop view. But thinking about mobile from the start prevents us from getting into trouble later; no one wants to take the time to revamp a desktop-centric website to work on mobile!
Disadvantages of Mobile First
Setting style declarations and then overriding them at higher breakpoints can have undesirable consequences:
More complex. The further down the breakpoint hierarchy you go, the more unnecessary code you inherit from lower breakpoints.
Higher CSS specificity. Styles that have been reverted to their browser defaults in class name declarations are now more specific. This can be a headache for large projects when you want to keep CSS selectors as simple as possible.
More regression testing is needed. Changes to CSS in lower views, such as adding new styles, require regression testing for all higher breakpoints.
Browsers cannot prioritize CSS downloads. At wider breakpoints, the classic mobile-first min-width media query doesn’t take advantage of the browser’s ability to download CSS files in priority order.
property value override problem
There is nothing wrong with overriding the value itself. CSS is designed for this. Still, inheriting incorrect values is not helpful, and can be onerous and inefficient. It can also lead to increased style specificity when you have to override a style to reset it to default, which can cause problems later, especially if you use a combination of custom CSS and utility classes. We won’t be able to use utility classes for styles that have been reset with higher specificity.
With this in mind, I pay more attention to default values when developing CSS. Since there is no specific order and no specific chain of values to follow, this allows me to develop breakpoints concurrently. I’m focusing on finding common patterns and isolating specific exceptions in the enclosing media query scope (i.e. any scope with a max-width set).
This approach opens up some opportunities because you can treat each breakpoint as a blank slate. If a component’s layout looks like it should be flexbox-based at all breakpoints, that’s fine and can be coded in the default stylesheet. However, if Grid seems more suitable for large screens and Flexbox is more mobile-friendly, then these can all be done completely independently when CSS is put into the enclosing media query scope. Also, simultaneous development requires you to have a good understanding of any given component in all breakpoints up front. This helps to identify issues in the design early in the development process. We don’t want to go down the rabbit hole of building complex components for mobile, and then get the desktop designs to find that they are just as complex and incompatible with the HTML we created for mobile views!
While this method isn’t for everyone, I encourage you to give it a try. There are many tools to help with concurrent development, such as Responsively App, Blisk, and more.
Having said that, I don’t think the order itself is particularly relevant. If you’re used to focusing on mobile views, have a good understanding of what other breakpoints require, and prefer to work on one device at a time, then by all means stick to the classic development sequence. It’s important to identify common styles and anomalies so you can put them into relevant style sheets – a manual tree-shaking process! Personally, I find this a little easier when working with components across breakpoints, but it’s by no means necessary.
news related post is here ……