Orthogonality with CSS

Openweb.eu.org > Articles  > Orthogonality with CSS


In the previous article, we recalled the concept of separation structure / presentation.

However this principle is in fact a sub-principle of a larger whole that is called the orthogonality.


(Note : this article was previously published in French a few weeks before this translation –if you have any feedback on the translation made by Nicolas Hoffmann and John Elbing, please let us know.)


In mathematics, the orthogonality is defined as : for example in a coordinate system in two dimensions, the components of the mark are orthogonal, that is to say that it is impossible to express a function of the other . For those who have more advanced mathematics, this is called the linear independance, that is to say, none of the components may be a combination of the other.

For what interests us, namely the websites, the metaphor gives a good idea of orthogonality, however, it is not exactly that. sourire

It takes more than understanding the concept of orthogonality as the ability of various technologies to work together without mutually telescoping, meaning without a walking each others toes.

We somehow have three dungeons :

  • Structure (the HTML) ;
  • Layout (the CSS) ;
  • Interactivity (JavaScript).

These three dungeons must be able to communicate together through various gateways. In the previous article, we studied how the HTML could communicate with CSS, let’s go further now !

Orthogonality seen from CSS

As this series concerns CSS, we will stick to study how a CSS can allow to respect this principle of orthogonality.

For example, allowing from CSS as much flexibility as possible for the HTML is a first step to the orthogonality principle – what we discussed in the previous article : avoid too strong coupling between the CSS and the HTML structure.

If the HTML offers classes and ids to allow to attach styles to elements, the CSS should do the same to allow JavaScript to do its work independently.

We often speak of attaching styles to HTML via JavaScript, but in fact, we should attach CSS classes to the HTML via JavaScript (and not direct styles).

Let’s start with an example : imagine a module having several states. The CSS must contain the module styles as well as styles of the various states of the module. In an accordion menu, each menu must have two states, eg .is-opened and .is-closed.

So he will not even have to ask questions when he adds the interactivity layer, he will handle the various “state” classes that the CSS developer will be made available. And of course, the CSS developer will arrange for these statements to be given priority over default styles of the module..

If these styles were to change, it would not impact the JavaScript developer but only the developer of style sheets. By doing so, tasks are more compartmentalized, and paradoxically they communicate better.

To use an analogy, it’s like object oriented : when you create an object, you must provide methods to manipulate it. The style sheet designer must do the same.

Qualitative evidence, but not only

If you doubt the importance of the concept of orthogonality, let’s randomly choose some good practices from the Opquast repositories :

They evoke nothing less than the concept of orthogonality (among other benefits : accessibility, semantics, etc.). The two first ones tell to not use HTML to do the CSS’ job. The third one is the opposite : don’t use CSS to generate HTML content. The last one indicates that JavaScript should not do the CSS’ job.

This concept of orthogonality becomes very important especially for teamwork : as it has been explained as an example in the previous paragraph, it is critical that each stakeholder be able do his work as independently as possible from others.

You might tell us that the front-end developer is doing both HTML et des CSS at the same time. Yes, it can be the case… during the template conception. Then, HTML can be changed by the back-end developer or by contributors using a CMS. And of course, they can make choices slightly differents than yours (!) in the base template. In other words, it is good as much as possible to have anticipated these “gaps”, and the concept of orthogonality will help you to do so.

This concept can even be a selection criterion when you have to choose a JavaScript plugin – jQuery in particular : its ability not to insert or manipulate inline styles can be an extensibility pledge… and shows cleanliness.


You may say that interactivity has some overlaps between JavaScript and CSS, especially for CSS animations. Of course, you can do with JavaScript some things that are feasible with CSS. It can be sometimes the only way to do with old browsers that can’t render CSS animations.

Even so, the principle remains valid : pure presentation animations must remain to style sheets. CSS has made tremendous progress in its animation capabilities. If you doubt, have a look at one of the last themes of CSS Zen Garden named Steel.

The concepts of graceful degradation or progressive enhancement are also better accepted by clients, which can avoid the use of fallbacks in JavaScript for things that could be done through style sheets.

Moreother, CSS animations take advantage of hardware acceleration, that is less evident for JavaScript code. We will prefer using them when it is possible, which will free up the browser and its JavaScript engine.



This article is part of the series “Great modern CSS conception principles”.

À propos de cet article

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.