1. Better (S)CSS: Principle of least privilege
I have often a feeling, that we try to follow best practice in all programming languages and framework, but our coding of HTML and CSS hasn’t change much. We just include new tools (adding includes, mixins, loops) but without really carrying if it is a code we can easily maintain, modify, if the next developer who opens the file will understand what we did.
I realised that my code doesn’t feel right. I had to search multiple files and in infinite indentation to find a selector and add !important because 15th selector for one element would be too much.
So I tried to work on the style how I code my CSS. One of first rules I applied is well-known for every developer — Principe of least privilege. Give the user/method/class/object… only what it requires, nothing more. As few options as possible.
How I transformed this to the CSS? I put element’s properties as low as possible — try to make them as specific as possible, not generic. This helps me to avoid overriding and thus adding selectors or our favorite !important.
1. Keep media queries as low as possible;
Readability > Lines of code
I remember when we started playing around with responsive design and implement them as extra paid features to some websites, the trend was to create different file for each breakpoint. The whole content of the file would be wrapped inside one media query.
Time has changed and with tools for minifying and grouping media queries, we don’t need to think where to put media queries to make stylesheet as small as possible.
Then where we should put media query selector?
— as low as possible. Ideally to wrap only properties of single selector.
Why?
Media query defines how a property of element changes according to then screen resolution change. Not element, the property!
On the left we tried to minify use of media query selector by wrapping the whole content. This example is quite small and the problem of readability is not that obvious, but with multiple media queries it will become a hell.
In the middle we wrapped a font-size and pseudo-elements inside the media query. The readability is better, but on the first sight its very hard to see that font-style for the item_child has changed, because it is not directly under the class name.
On the right we have wrapped only properties. Readability here is much better.
You can argue that its much longer than the solution in the middle, but in the end, our compiled css will be exactly the same. So Readability > line counts.
2. Don’t override default value by media query value
Specific > Generic
In general I try to limit all overrides of properties to minimum. It just doesn’t feel right to define 4 different values for the same property of one selector, when only one is used (for one screen size).
If there is a property, which has certain (default) value for tablet and desktop in our case font-size, background, font-weight and different value for mobile, put both these values in their media query selector. If I should write it as a pseudo code, the right side would be based on the principle of least privilege I follow (not generic — but specific).
If a property changes based on screen resolution, I put it only inside media query selector, no default value. If not, it will be only as a default selector property. Like this:
In this case we’re sure that all properties have same weight (number of selectors) if we need to override values, they are grouped together by the resolution and it’s easier to read and change them later.
3. Define limits for Media queries
I’m sure you’ve already seen rules like these when inspecting the code. Horrible, isn’t it :)
This stylesheet behaves like a woman — “let’s make the width 320px”. “Oh wait! 380px will be better.”, “Or 420px?”, “Nah, 460px will be the best!”…
Why the browser needs override the same value 5 times? I haven’t done any test and it probably doesn’t slowdown the overall performance, but I’m sure it does not help it either.
And it’s ugly!
Let’s modify the original queries by adding a max-width to each media query selector to have always a max and min limit:
And this is what it will produce in the brwoser — only one rule for the property height:
Looks better, doesn’t it?
You can tell that it seems like more writing, more lines of code, or complicated etc. But the approach to cleaner code is to follow (some) rules, keep it consistent, easy to change and easy to read and understand for you and anyone who will open your source code. And these rules work for me.
Here is an example from one of my projects.
One note here, instead of calling @media screen and (min-width: …) and (max-wdith: …) {}, i have defined my mixin’s small (mobile only), medium (tablet only), small-medium (mobile and tablet), large (desktop only), medium-large (tablet and desktop).
Let me know what you think about this approach.
