Or why SCSS is the future.
CSS (Cascading Style Sheets) was created to describe how a page should be presented in a markup language like HTML.
Over the years CSS has added many features, with CSS 3 being the most modern specification using modules to allow for new features, such as media queries that allow for easy manipulation of the content to fit the size of the display.
If I wanted a basic button, HTML would be:
But that doesn’t look very nice, so we’d rather add some colouring to it, maybe have a blue button:
That’s all nice and good, currently using inline styling (you can check it by using right click > inspect), but what if I wanted the same button ten times?
That’s when we start using style sheets, using classes such as “button blue” to create our blue button.
The problem comes when the style sheet starts becoming larger, how do I as a developer manage it all?
One possible solution is to create and link multiple stylesheets, but then we have the issue that we might want a custom style on one page that is not on another page. And we start writing more specific selectors on each page as sometime in the past in our gigantic pile of spaghetti CSS we wrote a quick target thinking that no one would ever want to be more specific.
And after all of that one has to minify their CSS to optimize site loading times, keeping a second copy of their CSS, which would make indexing quite fun by not allowing blanket rules like ignore all .css files while developing.
And in comes SCSS, a pre-processor that compiles to CSS, allowing for the use of NPM tools to automatically compile and minify your SCSS to CSS, reducing the number of manual steps and thereby reducing the chance of human error.
But this seems to be a recommendation of NPM rather than SCSS, so why should you use SCSS instead?
Look at the below example:
The above pen shows some of SCSS’s greatest strengths, the ability to nest classes and ids within parent ones.
If one nests a class within another one, it applies to any of the root’s child classes that apply. For the above example, blue applies to any child, one does not have to mention it within the direct child div, one could create another 5 child divs and then only use the blue class. If one wanted only to target the direct child class, the greater-than sign (>) is used instead.
Then there one of the most common features of SCSS that you would use, the ampersand (&). This allows you to target a specific set of classes on one div, e.g. the button class must include “button green” in the above example. One can even create suffix options such as “button-red” in the above example, but then the base styling of the button does not apply.
Overall, this allows us to write less styling, reducing the amount of code, which makes it easier to have special buttons that extend from others, just tweaking it slightly for the correct circumstance and you only have to update the base styling of the button if, e.g. the padding is not what you’d like for all buttons.
The other feature which should be your most used one is the ability to use variables in SCSS. Just like PHP, SCSS uses the dollar function to declare variables, for example, instead of using $grey, we would declare it as:
And then you just re-use $grey for any grey. Don’t like that grey anymore? Just update the hash code in one place rather than attempting to find and replace across the database.
SCSS imports cannot be stressed enough if you haven’t been using separate style sheets due to wanting one large file to be served for faster loading, this will make your life a lot easier.
By using the import ability of SCSS, one can create sub-files that contain the SCSS that you have written. You can then also easily add extra SCSS files or styles, such as having a Christmas theme that you keep in one file that may have a different, themed background image.
The other advantage is that you can comment out imports, which can help you debug styles by helping to isolate where the issue comes from if there is a lot of overwrites. The ordering of your imports also helps you manage overwrites.
For SCSS, use an underscore in front of the filename to denote that it is a partial file, this means that the file will be imported in another style sheet. This is to allow for faster processing, especially as your style sheets grow exponentially larger.
SCSS functions mixins
In the first code example, we showed the ability to have different buttons based on nesting them correctly.
The question now is, what if you wanted to create ten different buttons with different colours, where the name expresses the colour? Writing so much duplicate code would be an easy reduction in a programming language like Java or PHP whereby one can use functions. SCSS uses a method called mixin, which is a function that does not return a value.
In the above example buttons are generated based on a list of names and colours. Now, the above example is not that useful for you to use as it’s not much of a reduction, but what if instead it was a listing of images? We would be able to have a quick overview of images, any change to the mixin in one would apply to all, and we could even create so that it uses breakpoints, whereby the first image URL is the largest, then medium and then small, allowing for more efficient coding and easier maintenance.
After looking at the great advantages that CSS bring us, why not always use it? The only situation that I can think of for not using SCSS over CSS is if you can’t install node packet manager.
For us at Valkyriweb, using efficient tools such as SCSS that allow us to build client sites faster while reducing maintenance, can allow us to build cheaper, high quality, custom sites at prices that are affordable for our clients.