Most people starts with variables, but for me , if there is one feature that i needs to pick, i will choose "Partials". Why? Because of the fact that the code becomes more clean, precise, modular, and maintainable. Just like the concepts of partial HTML in AngularJS wherein, we create a partial folder and cut paste chunks of code into individual HTML files without needing the head, body tag etc, and later include them via ng-include where angular behind the scenes use the Ajax call to get the partial at the specified area in the HTML , pretty much the same idea has been applied here as well.
In our normal approach, we keep on writing css in one single stylesheet. And for a normal project, the lines can range anywhere between 4000 - 10,000 lines of CSS.
So what if i have , say a:
Now that we have the app.scss set up, we need a compiler that will compile the scss file and give us a css file with the same name.
If you are using a tool like Prepros, ( Paid, but awesome ! simply awesome, go for a 30 day trial and explore the features ) or Scout ( free ), then feel free to sit back and relax. The headache of installing node, sass, ruby, gem and the horror & fear of using command line can be totally eliminated.
To make it simple, we will use the scout for demo, but will also include the command line steps which would come in handy as well ( Note that if you are inside a proxy of your company network, then Node.JS, ruby, gems, etc may not install correctly unless you by pass it using the correct port and userid / password combo. Just downlaod the scout which inturn contains the gem and ruby inbuilt )
Here, lets point the right folders to the right inputs as shown above. Set the environment as "Development" since we are currently creating the css output for ourselves. If we need to generate a css aimed at production, then choose "Production"
The output style defines how the end css should look like.
The expanded will be our regular css style with one property per line.
The Nested will be pretty much the same, but the brackets alignment will be a bit different.
The Compact will be one css class per line with properties stacked one after the other( like float:left )
The Compressed will be the entire css in one single line ( This will be having the smallest size, ideal for production builds , but least readability )
Hit the Play button to the right of the project name and compiles the sass files and creates the corresponding css styles. Click the image below to see its enlarged version.
Note that the css is generated by the compiler. Not us.
To see the thing in action, lets write a bare minimum style in our _home.scss partial.
And the moment we click Ctrl + S, we can see that the Scout detected the change and auto-compiled and logged in the same.
Lets refer the app.css ( and not the app.scss ) as an external stylesheet and run the same and see the output being reflected in the browser.
Note that the order in which the css will be created, is the same order which we imported the partials in the app.scss. That is, if we had written the normalize/reset styles, it will come first, followed by the home, landing, contact, grid-view and list-view styles .
The final app.css output will be as shown above.
The number of partial files can be hundreds. Its just that we need to import it as needed in the app.scss accordingly.
References:
In our normal approach, we keep on writing css in one single stylesheet. And for a normal project, the lines can range anywhere between 4000 - 10,000 lines of CSS.
So what if i have , say a:
- Home page,
- landing page,
- contact us page,
- grid-view items page,
- list-view items page
And we need to divide the work among our team mates , assuming 5 people are working in parallel.
We might come up with an approach where, we use a common reset.css or a normalize.css and then, assign each page to each person, where each page is created in a seperate css stylesheet and then cut-pasted into a single my-styles.css stylesheet ( risky, and chances of missing styles or overwriting the classes someone has written..not recommended ) or referring the individual stylesheets as an external stylesheet using link attribute. ( This too is not recommended as the best practices says, reduce the number of requests that a browser need to make inorder to render your HTML at the fastest possible time. Each css stylesheet means browser needs to send that much request to download the assets that it requires to render the page properly. But the advantage being, once downloaded, the same is cached and so next time onwards, the page loads faster as the file is being accessed from the browser cache. Best practice says, reduce the number of HTTP requests as much as possible. If there is 10 css files, 20 img files, 15 javascript files , then the browser has to send out 45 request in effect. )
What if we could club the advantages only?
We could divide the stylesheets and keep it separately based on individual pages being created by individual developer , but in the end, import it all together so that the end result is a single css stylesheet ( which can be a collection of N number of sass partials.. May it be 10 or 100, it doesnt matter since the pre-processor doesnt care about the number, it takes the partials, combines it in the order specified and outputs one single css stylesheet.
The way we define a partial is by using the "underscore at the start" of the filename. The dot extension is optional as well. The underscore tells the compiler that this is a partial and so the compiler should not create a separate css, instead, this will be imported inside a main scss stylesheet (app.scss ) We can copy paste a normal css into an scss file and the same will still be fully valid.
So if we take our above example, then our folder structure will look like:
Here, inside the sass folder, we have an app.scss ( without the underscore ) and at the same level, we have a partials folder inside of which we hold a series of partials with an _{filename}.scss format.
The app.scss is the only file that will be compiled by the sass compiler and the corresponding app.css stylesheet will be generated dynamically inside the css folder. ( Provided the path is pointed correctly ). Its a good practice, only to use the app.scss as a container of partials where they are imported one after the other. We dont write any styles inside of it.
What if we could club the advantages only?
We could divide the stylesheets and keep it separately based on individual pages being created by individual developer , but in the end, import it all together so that the end result is a single css stylesheet ( which can be a collection of N number of sass partials.. May it be 10 or 100, it doesnt matter since the pre-processor doesnt care about the number, it takes the partials, combines it in the order specified and outputs one single css stylesheet.
The way we define a partial is by using the "underscore at the start" of the filename. The dot extension is optional as well. The underscore tells the compiler that this is a partial and so the compiler should not create a separate css, instead, this will be imported inside a main scss stylesheet (app.scss ) We can copy paste a normal css into an scss file and the same will still be fully valid.
So if we take our above example, then our folder structure will look like:
Here, inside the sass folder, we have an app.scss ( without the underscore ) and at the same level, we have a partials folder inside of which we hold a series of partials with an _{filename}.scss format.
The app.scss is the only file that will be compiled by the sass compiler and the corresponding app.css stylesheet will be generated dynamically inside the css folder. ( Provided the path is pointed correctly ). Its a good practice, only to use the app.scss as a container of partials where they are imported one after the other. We dont write any styles inside of it.
/*app.scss*/ @import "partials/reset"; @import "partials/home"; @import "partials/landing"; @import "partials/contact-us"; @import "partials/grid-view"; @import "partials/list-view";
Now that we have the app.scss set up, we need a compiler that will compile the scss file and give us a css file with the same name.
If you are using a tool like Prepros, ( Paid, but awesome ! simply awesome, go for a 30 day trial and explore the features ) or Scout ( free ), then feel free to sit back and relax. The headache of installing node, sass, ruby, gem and the horror & fear of using command line can be totally eliminated.
To make it simple, we will use the scout for demo, but will also include the command line steps which would come in handy as well ( Note that if you are inside a proxy of your company network, then Node.JS, ruby, gems, etc may not install correctly unless you by pass it using the correct port and userid / password combo. Just downlaod the scout which inturn contains the gem and ruby inbuilt )
Here, lets point the right folders to the right inputs as shown above. Set the environment as "Development" since we are currently creating the css output for ourselves. If we need to generate a css aimed at production, then choose "Production"
The output style defines how the end css should look like.
The expanded will be our regular css style with one property per line.
The Nested will be pretty much the same, but the brackets alignment will be a bit different.
The Compact will be one css class per line with properties stacked one after the other( like float:left )
The Compressed will be the entire css in one single line ( This will be having the smallest size, ideal for production builds , but least readability )
Hit the Play button to the right of the project name and compiles the sass files and creates the corresponding css styles. Click the image below to see its enlarged version.
Note that the css is generated by the compiler. Not us.
To see the thing in action, lets write a bare minimum style in our _home.scss partial.
/* _home.scss */ html{ height:100%; } body{ min-height:100%; background-color:#004c70; }
And the moment we click Ctrl + S, we can see that the Scout detected the change and auto-compiled and logged in the same.
Lets refer the app.css ( and not the app.scss ) as an external stylesheet and run the same and see the output being reflected in the browser.
Note that the order in which the css will be created, is the same order which we imported the partials in the app.scss. That is, if we had written the normalize/reset styles, it will come first, followed by the home, landing, contact, grid-view and list-view styles .
The final app.css output will be as shown above.
The number of partial files can be hundreds. Its just that we need to import it as needed in the app.scss accordingly.
References:
No comments:
Post a Comment