Responsiveness is not a luxury but a necessity these days in web development. The percentage of usage of mobile devices is increasing largely making support for mobile devices a must.

It can be difficult to write media-queries especially when not using libraries like bootstrap, tailwind but required to write them from scratch.

Just like everything good in frontend development, it can be done in different ways with different pros and cons and media queries aren't left out.

We have basically two approaches that can be followed:

1. Mobile-first approach.

2. Desktop-first approach.

The mobile-first approach means we style the web application with mobile devices in mind that is our default style will be mobile-driven and no media queries are required to support mobile devices.

This might sound like the perfect way to build but it comes with certain cons like watered-down design which is not necessarily bad but might be over simple when you scale to desktop.

The desktop-first approach means the web application is styled with the desktop first in mind. This is a more traditional way to build and allows for more freedom in styling applications.

Either one you choose to use, like Jonas Schmedtmann said Always keep both the mobile and the desktop in mind.

In a mobile-first approach, we make use of min-width in defining our application media query as demonstrated below:

@media (min-width: 660px) {};

This means to apply this media query when the width is 660px or above.

In a desktop-first approach, we make use of max-width in defining our application media query as demonstrated below:

@media (max-width: 660px) {};

This means to apply this media query when the width is 660px or below.

In writing either of the above approaches, we can do so in different ways (I will use the desktop-first approach here):

A common approach will be to write your queries with the tags within it as demonstrated below:

html {
    font-size: 12px;
}

@media (max-width: 600px) {
    html {
        font-size : 10px;
    }
};

The issue with this approach is, you have one gigantic media-query with all the Html tags defined in it. Also, imagine you have two to three media-queries for different screen sizes and you have close to a thousand lines of CSS code requiring this media-queries, it is a very tedious process of copying everything into each media-query and things start getting messy and not well maintained quickly.

There must be a better approach.

I will be using sass from here and assume you have some knowledge with sass. (A quick read up should be sufficient).

In sass, I can simply define a mixin (a reusable block of code) for each of my desired media-queries and use them in the tag itself as demonstrated below:

@mixin mobileScreen {
    @media  (max-width: 600px) { @content };
}

@mixin tabletScreen {
    @media  (max-width: 900px) { @content };
}

The mixin is defined for the media-queries, and the @content passed into the media query definition to allow css syntax and value possible to be passed in when called as shown below:

html {
    font-size: 12px;

    @include mobileScreen {
        font-size: 10px;
    }

    @include tabletScreen {
        font-size: 11px;
    }

}

we simply use @include to include the mixin in the code.

Now we don't need to copy the codes everywhere and it is reusable but imagine there is a way a single mixin can handle all the breakpoints and all we should worry about are variable names?

Let's do that.

@mixin responsive($breakpoint) {
    @if $breakpoint == mobile {
        @media  (max-width: 600px) { @content };
    }

    @if $breakpoint == tablet {
        @media  (max-width: 900px) { @content };
    }
}

We are simply defining a function here and a media query is returned based on the breakpoint name we pass.

Let's make use of it.

html {
    font-size: 12px;

    @include responsive(mobile) {
        font-size: 10px;
    }

    @include responsive(tablet) {
        font-size: 11px;
    }
}

I prefer this approach and think it is much more readable. I declare my mixin once, I don't have to worry about it anymore and simply make use of it passing in a readable name. I will call it the preferred approach.

I would conclude by saying, I will recommend either the good approach or the preferred approach, both very similar but you know the one I prefer.

Thank you for reading.