Working with styles usually follows the same pattern. At the beginning, we have plenty of ideas, motivation, and declarations about how great it will be this time. After all, previous projects gave us a lot of experience, yet the styling often didn’t turn out great. Why? Because the project time was limited. Because the requirements changed. Because the client changed the concept. Because the business realized the project was already over budget, and the time for improving quality had to be reduced. So, we start a new project, create the necessary files, and this rollercoaster begins another ride – sadly, on the same track. To be more specific, the project was probably fine, but our satisfaction with the code quality was not as high. And it probably never will be…

The problem with CSS is that it’s too flexible. It allows us to organize our code as we want, without any architectural restrictions. All we need is a few basic rules, and we can start coding (sometimes even without them). Of course, the programming world is looking for solutions that could transform CSS into something more predictable and less prone to errors. And yes, we’ve even found the answer: modules.

I’ve already written about the concept of modules. On my blog, there is an article about modules in JS. According to the most common definition, a module is an independent unit of an application with a specific task to accomplish. Modules do not have direct and uncontrolled impact on other modules, nor do they interfere with the functioning of others. Of course, a module can be dependent, but this dependency usually arises because the module is waiting for data from other modules. One of the key features of modules is their encapsulation.

Encapsulation is a term most commonly associated with object-oriented programming. In short, it means that a specific block of code is protected from external interference. In other words, external modules cannot accidentally or intentionally alter the behavior of the encapsulated module. A more visual way to describe this would be to imagine placing our code inside a “capsule” that shields it from the outside world.

So, if the key to “fixing” CSS is the concept of modules — why isn’t it that simple? It all comes down to the fact that styles in CSS apply globally across the entire web application. There are no built-in mechanisms that encapsulate our code or its parts by default. But are we really sure about that? To paraphrase a classic: hold my beer. Let’s take a look into the past.

BEM, OOCSS and Other Methodologies

Some members of the IT community have come to realize that CSS-in-JS still isn’t the perfect solution. Writing styles as JavaScript objects strips us of many default features that come with plain CSS. Sometimes, it even leads to bad practices—like using the !important declaration to override inline styles (since some CSS-in-JS approaches inject styles directly as inline styles into the HTML document).

For many years, the JavaScript world has been moving toward building applications based on component architecture. From the perspective of JavaScript code, creating and connecting multiple components is not a big challenge. CSS, although it tried to follow that direction, couldn’t quite keep up—mainly due to the lack of native language support. The solutions that began to emerge were mostly based on conventions—like BEM—rather than features built into the language specification.

In 2015, work began on ICSS (Interoperable CSS) — an extension of the CSS specification. Its main goal was to allow scoping styles to the component level, while still enabling access to global CSS selectors. Essentially, ICSS introduced two CSS pseudo-selectors: :import and :export. Their main purpose was to allow styles to be exported and then imported in a way that makes them available as an object, with local aliases used as its properties. A local alias is simply a name consisting of letters and numbers.

These approaches aimed to solve the problem of CSS code encapsulation. They brought a lot of satisfaction to developers, even despite the community’s complaints about long and complex CSS class names.

A Look Back

In 1996, Netscape proposed an alternative for styling websites – instead of using CSS, they introduced JSSS (JavaScript Style Sheets). The concept of JSSS was based on the idea that styles would be created using JavaScript objects. In 1997, it was officially implemented. Netscape promoted this approach as more efficient, claiming that it allowed full utilization of JavaScript’s capabilities as a programming language for calculations and style conditionality. However, JSSS lacked access to complex CSS selectors. If this concept had survived, it’s possible that the issue of CSS modules would have been resolved by integrating modules into JS. Unfortunately, that didn’t happen – no browser (besides Netscape Navigator) adopted JSSS into their codebase.

translation in progress...