Following up on the Sass Essentials course I watched, CSS to Sass: Converting an Existing Site which showed various techniques on converting an existing site from “vanilla css” to sass. As I mentioned before, WordPress themes utilize Sass, so if you choose to use the Underscores starter theme (which I’ve used on my own themes in the past), you can go to the site, select “sassify” and it will include a Sass version. This way you don’t need to take any extra steps to convert their CSS to Sass, as outlined in the course or summarized below. However, if I wanted to convert the CSS for my site at ShesGottaWriteIt.com, which was developed with Underscores but not with Sass, then I’d follow the lead of the instructor for this course.
The instructor walks you through the steps of converting your existing CSS to Sass and depending on your development workflow, there are aspects of the course that may not be beneficial for you – at the moment. For example, the instructor opted to use LibSass instead of Ruby Sass for “faster processing” and also managed all of the compiling with grunt sass or something of that sort (???). Clearly I blocked out parts that I knew were not applicable to my current workflow, especially because I’m not fully acquainted with the command line (which the instructor heavily used) and Netbeans IDE handles Sass compiling for me. Given my short-term goals and time constraints, I’m more comfortable getting acclimated with Sass in this environment than having to also learn how to navigate the command line – which I plan to… just not now – ha.
Concepts that were reviewed that I found helpful:
- Nesting best practices: Sass developers suggest only nesting up to 4 levels. I understand why nesting is use, but it doesn’t look like it’s saving anyone time. I’ve written code that nests the way the Sass compiles to, but we’ll see if that changes as I work on larger projects.
- Z-index: According to W3Schools, “the z-index property specifies the stack order of an element.” If you’ve ever worked in Microsoft Powerpoint and needed to move an object forward or behind, that is done through modifying the z-index property. You can apply that same concept to web pages, as exhibited through those annoying ass popups asking you to either login to a page or sign-up for a newsletter (or whatever) otherwise obstructing your view of the webpage content. All of that is accomplished by applying a higher-numbered z-index value to an element. The higher z-index value corresponds to a higher level in a stack, and vice versa. In the course, the instructor demonstrated how to create a set of z-index values & corresponding variables that allow flexibility during development so you wouldn’t have to constantly readjust properties for elements as you have preexisting z-indices and can then apply them based on the stack order you want to create.
The instructor share some tools that might be beneficial in conversion including:
- Hextractor – an site where you attach your css file and it analyzes and extracts all hexadecimal colors which you can use to create variables in Sass.
- csscss is a tool that analyzes your existing code for redundancies to identify blocks of code that can be converted to a mixin, which is a reuseable block of code, similar to the way you can create a class and re-use it on a variety of elements within your HTML. Mixins enable that feature within CSS.
The lesson on Css transitioned into an introduction on Sass libraries that come with features that help with development so you’re not creating and re-creating mixins and other features, especially ones that help manage media queries. The one included in the course was @include-media which makes it easy to create breakpoints for different devices, very important in the age of responsive web design. Once again, this library was installed using command line (zzzzz – lol) but I’ve bookmarked it for later. Also googled other media query libraries and found Breakpoint which also works well is Susy – the grid system that led me down this path of no return (hehehe!).
The instructor reviewed other popular Sass mixin libraries like Compass and Bourbon… both names I’ve come across in my research not knowing what it means and honestly I’m still not clear on this but I’m sure further development will get me together sooner than later. Once again, I didn’t follow along closely because there was a lot of command line installation stuff that had nothing to do with me.
After reviewing mixins the instructor talked about other tools like Autoprefixer which adds or remove browser prefixes for properties to ensure cross-browser compatibility… at least that’s what I think I got from that section. Mixins can handle this but apparently the Sass developers suggest using Autoprefixer modules. I found this and might revisit when I need it. I do recall reading that some developers are not developing websites and checking for cross compatibility for some of the really old browsers – possibly because they’re working under the assumption that the users are likely using more updated platforms.
Lastly, the course reviewed image sprites. What are image sprites, why they’re used and how to use them?
The instructor covered sprites using some command line module so I didn’t really follow along and decided to google for more info. Image sprites combine multiple image files into one image file and using CSS you’re able to grab and display the individual images you want with positioning properties. They’ve been adopted by developers because using one image in the place of 5 separate images only requires one server request, resulting in faster loading time & website performance. In my research, it’s used often for social media icons, instead of storing 100 million different icons and having to send requests for each of your accounts on Pinterest, Instagram, Facebook, Twitter, Linkedin, Peach… you get the point. You can also read this for more info.
*Bonus: in the process of learning about sprites I did a quick study on minifying and concatenating CSS. My unsubstantiated thoughts on this are that sites created now are so much more robust than yesteryear’s so developers are looking for ways to speed of up site loading, even with significantly increased internet speeds thanks to ISPs. So they minify and concatenate code to assist with this on the back-end.