Software Engineering principles applied to CSS

Share on Facebook0Share on Reddit0Tweet about this on TwitterShare on Google+0

Some of my thoughts about CSS developent. Think of more? Share in the comments and I’ll add them to this page!

Low Coupling

The principle of low coupling suggests that distinct parts of an application be as “stand-alone” as possible.

To illustrate: A very decoupled program could be available from the command-line first, then a GUI is built using that programs API’s. This ensures that the logic of the program is decoupled from the presentation. A developer can change the internal workings of the program without affecting the other aspects of the architecture.

Targeting elements based on their DOM order tangles up the visual presentation (CSS) with the structured content (HTML) – Highly coupling the presentation with the content.

Changing the name of your parent container shouldn’t detach your horizontal menu from its style.

Separate the presentation from the structure with the use of classes:

High Cohesion

Separating the concerns of CSS into different files allows you to create highly cohesive classes that, once in place, allow a great deal of flexibility in development. Areas of concern are:

  • Layout: positioning of elements, geometric dimensions
  • Style: colors, borders, backgrounds
  • Normalization: typography, element defaults

Separating the CSS into separate areas allows you to create highly cohesive “modularized” rules that have the bonus of being easily swappable:

  • Layout-full.css, layout-compact.css
  • Blue.css, green.css, red.css
  • Normalize.css

Any combination of the above files could be used to alter the presentation of the application without changing the content architecture.


If elements are targeted by semantic classes, instead of their order in the DOM, it is easy to modularize classes using the principle of inheritance:

This is a popular technique in many rapid development frameworks, such as Bootstrap, Zurb, and others.

Additionally, CSS may use the principle of multiple inheritance by using styles from multiple sources – such as a horizontal navigation getting its form and function from layout.css, and its color and branding from color.css files.


In software engineering, the most general use-case is often sought, as it will eliminate redundant future work. Nathanial Borenstien, inventor of the MIME type once said,

“It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter.”

Name classes based on their general use-case, rather than on their appearance, position, or other attribute.

If not, ‘The boss’ might ask you to change the submit button to green, but the in-code class will stay .button-blue  forever, because it is already in hundreds of places.

Naming classes on their general case avoids this problem, and also makes for easy discovery and maintenance by future programmers, or your future self.

Additionally, duplication of elements becomes easier. If not, you might need to duplicate the element somewhere other than the original place, and you end up with navigation in the footer called  .sidebar-nav


If using the principle of generalization, there may be some base class that is never intended to be used on an element on its own. To provide some level of abstraction, only declare universal attributes on parent classes.

Encapsulation (private styles)

By using the principle of inheritance, we can make some classes essentially private by namespacing their selector rules:

This ensures our style definitions don’t ‘leak’ into other elements, and can only be used within a specified parent element.

Share on Facebook0Share on Reddit0Tweet about this on TwitterShare on Google+0