If you are planning for a new development project, the best approach is Maintaining CSS Legacy with the use of SMACSS. Wondering what are these? Before diving into the main topic, let’s know about these terminologies. Let’s have a look:
Scalable and Modular Architecture for CSS is a style guide that examines your design process and makes it into a supple thought process. Basically, it is a practice to site development when utilizing CSS. It has 2 basic goals-
1. Enhance the semantic section value of a content and HTML
2. Decrease the HTML structure expectation
On the other hand,
CSS is an acronym for Cascading Style Sheets. It defines how the elements of HTML are to be shown on the paper, the screen on in other kinds of media. It controls the layout of several web pages at once.
This is an extension language of the CSS that is most powerful and stable. There is a wide assortment of frameworks built with it like Susy, Compass, Bourbon and more.
Now, let’s shed some light on the main topic – how to scale and maintain CSS legacy with Sass and SMACSS.
On several marketplace sites, the style sheets are probably written in Sass along with keeping the legacy CSS in mind. Undoubtedly, CSS makes it easy for a team to maintain stylesheets properly without losing any essential detail like the prevailing front end. This approach is based entirely on SMACSS that solves many problems handles by OOCSS and SMACSS, but require some ideas and modifications from areas like Toadstool and BEM.
Let’s start with SMACSS
It is categorized into 5 styles. These are – base, layout, module, state and theme. But when it comes to precise SMACSS, two things need to be skipped out – layout and theme.
In latest projects, the base styles are set to Normalize with some basic element styles such as margins, padding, colors and typography. Sadly, the marketplace CSS only comes when aggressive CSS resets were calm down and having some sort of unfortunate default typography styles. Changing these styles are not as easy as they seem, also, it is important they should not affect other CSS built on the top over the years. Despite the drawbacks, we make sure to treat the styles as similar as the base styles of SMACSS.
Speaking about the right approach, the module is not something global state class or a base style. SMACSS actually creates a distinction between the chief layout components like grid, sidebar, header and more. But this distinction is not essential and there are a few reasons for it.
1. Modules generally lay out their minor components as same as major components are spread out on the specific page.
2. Regardless of whether we’re 100% sure a segment will never be reused, there is no advantage in treating it any contrastingly to reusable segments.
The line among formats and modules is excessively fluffy for it, making it impossible to be worth keeping designs around as a special classification.
People have different perceptions about the module. But actually, these are reusable components without any information about their parent container. They are only dependent on the app’s base styles. So, it is wise to delete those extra modules without changing any part of your CSS.
When it comes to BEM double underscore syntax, it is basically used to scope child/minor components to a module. And, in order to minimize the applicability debt, using CSS child selectors liberally makes sense. On the other hand, the double hyphen syntax of BEM is used as a modifier to demonstrate subclasses or, when used in a blend with the is- keyword, module-particular state classes. However, setting the position, edges and width of the module would require learning of the setting it shows up in, these modules are in every case either full-width square components or inline components.
The module specific state classes are actually defined in the similar field to the module itself. However, it is essential to keep the global state classes apart.
Doing theme of eight marketplaces is a wise move, but to achieve this successfully, you need to set variables for the styles dedicated to site-specific in a configuration file.
Bringing SASS effectiveness altogether
The first file you need to include in your application.sass is _config.sass. In this, all the common value are assigned to global variables. This includes everything ranging from font sizes, families, colors to responsive breakpoints and even more.
Mixins have lots of power. Basically, it is a group of styles that can be used again across your CSS. The most common uses of Mixins is – handling vendor prefixes. Even the mixins are secured in their own directory known as mixins directory and are easy to access across the globe. You can also import some vendor mixin libraries for vendor prefixing and sprinting.
Make sure your grid system is more than just a module. So, in HTML, steer clear of using grid classes such as .span-5 and ensure to use Susy to keep section based widths in CSS close by the modules they have a place with.
3. Internet Explorer
At first, the use of HTML5 Boilerplate method was common to target the browsers, but that doesn’t mean that you need to send lots of styles coped to.It-ie8 to other browsers that won’t use them ever.
So, the best trick to generate standalone application-ie7.css and application ie8.css sheets for those browsers.
What should not be done?
There are a few things that should not be done if you are looking to get ultimate results. These are –
- Not aiming for readable CSS output
While composing modules like this, you can pick a class name and correct Saas file directly rather delving around in DevTools attempting to make sense of where a particular style is originating from. Moreover, Source Maps.
- Not Aiming to remove every aspect of duplication from the compiled CSS
In the nutshell, the main aim is to make development a piece of cake without affecting the performance. So far incorporating mixins in modules rather of @extending everything in locate hasn’t harmed anyone as far as crude file size gzip bites up to a large portion of the duplication – we’re sending around 39kb of CSS over the wire).