The attempt to structure CSS in large projects comes after the first release all together. One wants to prevent overwrite general styles and builds to be careful prefer a new class construct. Another problem: inconsistent implementation. A new Developers will be added to the project and will not be instructed in the guidelines laid down at the beginning or the specified directives are not implemented and observed.
The following: The result is unstructured code, which only after top-down approach of one Browser debuggers are understood.
Often the !important as last chance seen his adjustments to force the style. This creates a lot of “dead code” code that is not needed. The CSS file explodes.
Looking at the development of the CSS ecosystem in recent years, you can see that some did. A few years ago still Bootstrap the basis the styling for most projects, so today you have many different possibilities a project to set up. Different approaches can be combined. An even greater variety is created.
Recently, however, two approaches have crystallized out. Once the component-based structuring and once atomic disintegration into classes with only one CSS property. This is also reflected in Survey ‘State of CSS 2020’ against. The methods BEM (component-based) and Atomic CSS (atomar) enjoy high attention.
But what approach is a good choice for large projects? How should architecture look? Can do you maintain a clear structuring in the later process?
BEM is now very well known Frontend developers. It is a method to structure its CSS shells and build reusable blocks. The Elements on a website divided into blocks that can possess elements and modifiers. Scope the CSS definitions are thus limited to this component and the cascade effects of CSS restricted. There are hardly any other CSS definitions outside this scope on the Competent too.
Reusability is a great advantage here. If you do it correctly, individual modules can easy to transfer to other projects without much effort. In addition, this method has low specificity. In other words, with special requirements on the module, styles can easily be overwritten will be.
However, it is often difficult, especially at the beginning, to divide everything into such components. The Example in a card element a headline with a subheadline already a component, only because more often in the project? Or does it remain an element of the card component?
Furthermore, one often encounters difficulties in the later project when it comes to changes in style and Markup of the component comes. You define either another style of the component or duplicate this even with adapted style. There is a lot of double code and dead code that does not Effects more on styling. The use of repetitive styles is also not exactly defined. You try to solve this with the help of Mixins or you simply duplicate the corresponding properties.
1 2 |
// CSS Deklaration .Mt\(20px\) { margin-top: 20px} |
1 2 |
<!-- HTML --> <article class='Mt(20px)'></article> |
Atomic CSS , also ACSS, is based on for each repetitive CSS declaration to define its own class. This gives a distance upwards for example with the class .Mt(20px) .
This method is already in emerging frameworks and Tailwind.css used. Also Facebook has in its redesign built on Atomic CSS, making a much more efficient structure create an 80% smaller CSS file at the end, compared to the previous Development.
Look at the Facebook page more closely on a div element and the respective Style declarations of individual classes, the principle becomes somewhat clearer. Each class has exactly one Style declaration. This method no longer uses CSS descending selectors, whereby using the HTML element, you know exactly what styles are going on. A great advantage as you for style adjustments always knows exactly that there will be no impact in another place.
A disadvantage of Atomic CSS is that it has built up the complete way CSS changes. It's a big change that might hurt at the beginning. You link HTML and CSS more with each other, learning for years to severely separate them. Additional blows the HTML document is strong and becomes very unreadable. Here is an example:
1 2 |
<!-- HTML --> <div class='Bgc(#555555) C(#fff) P(20px) Mt(20px) Blw(5px) Blc(#000) W(50%) H(50%)'>Beispiel</div> |
It becomes clear that both approaches entail both advantages and disadvantages. But how about a combination of the two methods? This approach is precisely implemented with Cube CSS. She's with the CSS survey a new part of the listing and already has the interest of some front enders awakened.
Cube CSS is a new approach to the two Methods ACSS and BEM united. The core of this method is, most definitions already with global styles and Include high-level styles. That is, before a component is created, all external Effects defined. Colours, fonts, compositions are already defined. Here's a little a look into the meaning of Cube:
To create a easily readable and consistent structure in the HTML file, the individual Classes combined in groups. Instead of the square brackets, other characters can also be used to Grouping is important, grouping and holding the order. This gives an easy readability of HTML.
1 2 3 4 5 |
<!-- Beispiel mit eckigen Klammern --> <attribute class=“[card] [section box] [bg-base color-primary]“> <!-- Beispiel mit senkrechtem Strich --> <attribute class=“card | section box | bg-base color-primary“> |
Cube CSS extends the general CSS language. It does not try to develop the language again or to crumble, as it appears partly with BEM and ACSS. It takes the skills as the cascading property of CSS, attempts to get the best out of it. BEM and ACSS is partially suppressed.
Included is a solid architecture the A and O for scalable Cascading Style Sheets. It is important that all developers move on one line in a project and that take into account and comply with predefined established methods and rules. All methods have Potential to ensure good scalability. With Cube CSS, however, many advantages united. A lot of code is saved by global and compositional definitions. Colours and Fonts can be set and used token-based and the HTML structure remains clear. Adaptations to a later project stand are simple to implement in compliance with the method.
Nadine is a specialist in user experience design and front-end development. At actidoo, she deals with the creation of complex prototypes and the implementation of web applications. With her passion for qualitative UIs, she wants not only to give the end user a pleasure, but also to facilitate his use with intuitive operation.