Think outside of the box > Articles  > Think outside of the box


Think outside of the box”: here is an enigmatic title!

However, it is one of our greatest challenges as CSS developers: abstracting us from our environment and even from our own senses that can… set up some vicious traps.


(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.)

“Human” mistakes

Yes, we are human: when we create a CSS, we do it in a certain configuration in a certain context, we use properties to control rendering in the browser and… we use our eyes to see the results of our work.

However, this “framework” – although reassuring – that allows us to work, leads us to make some obvious mistakes when you think about it, and sometimes so hard to avoid in the heat of the action.

An example

Let’s starting from a very basic example: let’s imagine a “classical” design with three columns (200px/600px/200px), with a simple module that displays a message on a grey background in the right column.

You will often see this in the CSS:

.box {
  width: 200px;
  background: #ddd;

It seems to be ok: module is defined in a short and efficient way, according to what we “see”. Nevertheless, isn’t there something that surprises you? If we go back to performance advices, one of them was: don’t use pointless styles. If the right column is 200px-wide, why is this width redefined in our module? In this case, this style is pointless.

Fortunately, making responsive web sites usually forces us to think “more flexible”: imagine that our widths are defined with percentages, this necessarily implies that our module can’t be specified in pixels, as it will have to stretch to the width of our right column. That’s better!

If you are not still convinced, another example: let’s go back to our first example. Now imagine that the right column is linearised in the lower resolutions (the three columns are stacked). So, if we had specified width, we would be bothered again with our module that does not stretch. Of course, we could readjust this value via a media-query, but it was already avoidable upstream!

Still not convinced? Let’s come back again to our first example. The template has to be adapted, your colleague decides to adapt the columns in 200px/550px/250px instead of 200px/600px/200px. The specified with of our module is still giving us problems. Worse, if the right column should not be reduced but enlarged, who knows what problems it could still add?

In short, less styles not only allow us to reduce the CSS weight, but it also simplifies our job and/or upcoming changes… and maintenance.

Use context

If your senses make you do too much work in creating styles, here is an unorthodox but very effective advice: be lazy. Do not redo what has already been brought from outside of the module context. Let your module breathe, make it independent, let it live its life outside of the rest.

Typically, if you have a look at OOCSS approach, one of its basic premises is to separate positionning of a module from its own design. In our example, if we do this, we find that… there is no “positionning” style, they are brought by the module’s context.

So, when you define a module, ignoring its context is not a disadvantage, take advantage of it to define the module as independant as possible. This module will certainly adapt itself to whatever context it has (which is going to avoid a lot of problems in responsive), and you will make lighter, more reusable and flexible styles.

Avoid “magic numbers”

A magic number in CSS is a value that is justified only by a “it works”. But it works only in some special cases, often coming from our configuration. In general, it is a frequent mistake made by beginners that are not comfortable with the box model, typography management or when they need to go so fast that the CSS is abused.

These magic numbers bring a lot of problems:

  • they are working only in a given case: for example with a specific browser with default font size;
  • they are not pledges of sustainability: if a developer has to update the CSS, he will not understand where this value comes from, especially if he has a different configuration;
  • another problem for this developer: how can she be sure that this house of cards is not going to collapse?

In short, it is not reliable at all ! Ideally, avoid this at all costs.

The question

Ask yourself the right question: on what does the value that I want to use really depend, from which context?

It may be a simple positionning in a block, for example this block should be stuck to the right in its parent, which gives us:

position: absolute;
right: 0; 

or by a simple floatting.

It may be function of the typography – and a lot of thing are depending on it if you use the flow properly – and in this case, we will prefer values with units that rely to typography, typically the em’s.

Although this unit has some bad reputation for how it works – proportional to the size of its parent – in fact, we must understand this: you will make the property depending on the font size. In other words, instead of choosing a magic number that will only work in one specific case, you use a unit that is based on a context, which will evolve with it and will even offer you an abstraction layer: regardless of the actual value an em (depending on context this can vary), you will control not rendering but its evolution.

Don’t forget that everything that is defined in function of the typography allows to make possible for the user to zoom without breaking your CSS, using global zoom or text zoom.

Going further: letting go

“Thinking outside of the box” is going to bring you to an unique conclusion: letting go. The Web is like this: you don’t have control and you will never have it. The reference of this subject is A dao of web design, written by John Allsop.

This article has been written 14 years ago, and it is still correct: with hundreds of devices (mobiles, tablets, etc.) and thousands of possible parameters (by default of modified by users), all combined with responsive, you have so many differents cases that you can not control it while respecting your users, their diversity and their preferences.

However, letting go doesn’t mean loosing control.

It is very well explained in Nicolas Hoizey’s article (in french) «lâcher prise sans perdre le contrôle». This article is dealing with the em unit, however it can be applied to any relative unit: you do not impose your choices to your visitors (which is impossible anyway), but you can manage these choices without multiplying your work.

Another way of thinking

One might think that letting go is binding and / or killer of freedom for the web designer, it is quite the opposite: not only do you allow yourself to satisfy as much the smartphone user and the tablet user, as those on a classic computer with a giant screen with a large zoom by default. And you do it with a single code!

Sometimes, I’m amazed by a use case – an “exotic” device I’ve never thought of – that works perfectly, just by making a flexible CSS! :)

It’s the same amount of work: one could believe that this way of thinking involves much more work. This is not true: with a little practice, some tools (not essential), it does not take more time, and sometimes you win more… by defining less styles! (not counting their robustness)

As the first article showed, these principles must be considered as a coherent whole: thinking outside of the box will allow you to create lighter, more performant, more flexible and more maintenable CSS.

To do so, some key points:

  • separate positionning from design for your module;
  • create as flexible and fluid as possible;
  • avoid magic values;
  • use context to avoid too much work for positionning;
  • and always ask yourself from of what your CSS values must be function, if they should be function of something.

Of course, you have to test, test and test. But you already know this, don’t you?

References, further reading


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

About this article

Your comments


Warning, your message will only be displayed after it has been checked and approved.

Who are you?
Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Follow the comments: RSS 2.0 | Atom