CSS Margin VS Padding

Today, while working on a tiny project, I suddenly wondered why I usually favor margins instead of paddings to create space around elements in CSS. At the moment, given that there are deadlines, I decided to push aside the question, but before that I did a quick search, and opened a Stack Overflow question about the matter so I would not forget about this existential question of mine.

At some point during that tiny project, I came up with a situation that definitely required paddings, and not margins to solve. The situation was this: I had two elements in a sort of lightbox effect. I wanted the “lightbox” to close whenever the user clicked on the element that was sitting behind covering the full window, but not when the user interacted with the element sitting in front, ie the content of the lightbox. The solution was simple, add a click event handler on the back element that closed the lightbox, and a click event handler in the content element that only stopped the propagation of the event. That way whenever the user interacted with the content element the click event would never reach the back element, thus not closing the lightbox.

This method worked well, but I wanted users to have a little room around the content where they could safely click without closing the lightbox. For this, using a padding on the content element was the way to go. In this situation a margin would not have worked because you can ‘t click the margin of an element. Clicking the element was required because only that way could we prevent the click event from bubbling up to the back element.

In the stack overflow question, someone mentions that they usually use padding only when they want to increment the space inside a visible box. I’ve now presented you with another case, although this ones is more of an edge case.

I think most of us prefer margins, but there are cases where padding is the right and maybe only way to go.

CSS Variables, Yet Another Step in the Wrong Direction

From the first time I learned about CSS variables some time ago, I noticed it was a stupid implementation. This is what we get when the people writing the specifications are not one bit close to the real world development scene. How can a person who doesn’t write CSS on a daily basis know what the best way to implement something is. Add to that the fact that variables in CSS are completely useless by nature. However, the “developers” asked for them, and they got them.

CSS variables are still something that lives in the future. They are like an incredibly stupid monster that lives in another dimension, but that has managed to open a portal, and is now showing one of its ugly paws through it. But I’m not the type to mix science fiction with reality, and I don’t usually write in this style, so I’m going to stop now.

Going back to my usual ranting style, let me tell you why CSS variables are stupid, and dangerous. But first, lets take a look at the motivation.

I Want to Feel Like a Big Pants Geek Boy
Or Why CSS Variables

It is my belief that CSS variables come deep from the need of designers to feel like developers. I’m not trying to insult designers here. I have great respect for some of the work that great designers have done, but now that the web has given birth to the front-end wave, there are a lot of designers out there who want to feel like they can call themselves front-end engineers. This is not a good thing. Designers should be proud of being designers simply because their work is amazing. But being geek, nerd, and coder is the fashion now, so many designers want to be that too.

Today I read this on a blog post:

If there is one thing a language needs to qualify as a programming language, it’s variables; they’re incredibly useful, save us a bunch of work and typing, and improve coding all-round.

This is simply a demonstration of both, the need of some designers to feel like they can program, and their lack of knowledge of programming languages. But I’m not going to start attacking people just to make me feel better. I think I should just continue attacking CSS because after all, that is what is ultimately wrong. If we really want to make CSS better, we need to throw the current specs out the window, and start anew.

The Nightmare of CSS Variables

I wanted to have a bit of a better base for my arguments, so I decided to head to the source of the problem. I searched for the W3C specification of CSS variables. It is still an Editor’s Draft, but in this stage we can begin to see some of what is wrong with CSS variables. Take a look at this example, taken from the W3C site:

:root { var-color: blue; }
div { var-color: green; }
#alert { var-color: red; }
* { color: var(color); }

<p>I inherited blue from the root element!</p>
<div>I got green set directly on me!</div>
<div id='alert'>
  While I got red set directly on me!
  <p>I’m red too, because of inheritance!</p>

I really hope you see what is wrong there, but if you don’t, I’ll give you a hint: the paragraph element can be a different color depending on where it is, event though you specify a “specific” color for all elements. This is because of the stupid implementation of scope.

The scope of the variable is resolved in terms of the location of the element in the HTML structure. What!? This is wrong, and you can go and find as many justifications for this as you want, but it won’t change the fact that this is just wrong. It would have been better to implement namespaces rather than this kind of scope.

This behavior is defined as “cascading variables”. In a sense, it is not even a scope chain. It is a freaking cascade! Why would you want your variable values to cascade? This should be called randoms instead of variables, because the value of the variables will change almost randomly depending on where the element is in the html.

This cascading behavior introduces inconsistency. Inconsistency is enemy of robustness because it creates unexpected behavior. However, CSS variables introduce a whole lot of inconsistency and complexity to an already complex language. The bad thing about this complexity is that the complexity is not in the language itself, but in the way the language has to be written in order to be efficient. In other words, writing complex, hard-to-maintain, CSS is a requirement so much they almost advertise it as a feature.

Who Needs Variables Anyway?

I like to believe there is a better way to write CSS. I’ve been recently experimenting with what I call Subscription Based CSS. It has allowed me to create more consistent behavior, easier-to-maintain CSS, and a smaller code base. Explaining Subscription Based CSS is out of the scope of this entry, but the basic idea is to develop sets of styles, and simply add selectors to them. This eliminates completely the need for variables. Think of this example:

color: #bada55;

We have defined a color set. Now, whenever you need a certain element to have that text color, you simply add a selector to the rule set. For example, if you want all your h1 elements to have this color, you simply subscribe them:

h1 {
color: #bada55;

If you also want elements with the class “badass” to have this color, you subscribe that selector too:

h1 {
color: #bada55;

There is no need for a variable called var-badass, and there is no unexpected behavior. The .badass elements, and the h1 elements will always have the same color regarding of cascade values.

You can apply this same principle to any CSS property, and you can do more than variable can do. For example, if you want elements to have the badass background color, and white font color for nice contrast, you define that set:

h1 {
background-color: #bada55;
color: #fff;

This is a much better way to deal with constant values.

F! Semantics

In my early days, I was pro-semantics. Semantics were the hype back then, and I saw a lot of value in that. Semantics rely heavily in class names, and we learned that using class names that described the visual representation of the element was bad. This means that if you have a class like “centered_text” you are doing it wrong. Why? For the sake of semantics, of course.

Nowadays I’m not as big a fan of semantics as I used to be. Class-based semantics are a redundant task that has little added benefit for the end user. They are of great benefit for robots, and automated machines, but we do web for users, not robots. Once you forget semantics, writing subscription based css is really easy.

I don’t think CSS variables will go away. They are just another feature in the web that takes us a bit further from where we should be, and that diverges us a bit more from the direction we should be following, but like everything else, it is up to the developer to use the feature or not. I’m sure they will be loved by many because we tend to see any new feature like a new toy we must use as much as possible. I think we will start seeing CSS frameworks that claim to be the perfect solution for CSS variables, just like it happened with grids. With that in mind, I can safely say that I saw the future, and it was awful.

grumpy cat