Get to Know The Lobotomized Owl Selector

The lobotomized owl selector is an exciting CSS concept which helps you make a decent content flow in your design with just a few line of code.

This methodology is way underused but handy. It is useful in complicated use cases, and we can make a little bit better architecture with the help of it. For me it is a shame that I hardly used – and knew – this technique.

This is not a new technique and I think the owl selector is an exciting CSS concept so its time to summarize it again (mostly for those who didn’t know it)!

What is the Owl Selector

The selector is really simple and contains two universal and an adjacent item.

* + * {
    margin-top: 1.5em;

Fundamentally, this means that select every element which has an adjacent item right before it. We choose everything in a defined scope except the first one because in this case there isn’t any element before of it.

The Owl selector looks a little bit awkwardly and unnatural but don’t let this fool you. It is a powerful line. If you think about it is still a simple selector which aren’t over specified; of course, it is too generic, but we can handle that. Using the selector, you can separate your components from your margins – and compose a vertical flow with ease.

See the Pen Presenting the Use of the Owl Selector in a Small Component Environment by Adam Laki (@adamlaki) on CodePen.

As I read and saw the discussions, it gets mixed feelings. Some say in a complicated system there isn’t any place something like this. But come on in CSS you can make everything in a lot of ways why this clever trick can’t be one way. So give it a try besides your ideas.

As you guessed the naming comes from a continuously starring owl which sees the nasty things that you did with CSS in the last week. Just kidding but we can look at the similarities, and the naming was chosen by the “inventor”.

The History

This concept was introduced by Heydon Pickering in 2014 in an “A List Apart” article. Heydon is an accessibility guru who is running a lot of related project like Inclusive Components. It solves an existing problem – as you see it in the using section – and as Heydon say there was a lot of work to come up with it. Of course, back then in ’14, there wasn’t any new feature in this three-character, this method just combined the existing resources.

I’m currently reading Heydon’s book – Inclusive Design Patterns – which is a severe piece for everybody who wants to make a more accessible web.

The Performance

We learned from the early days of our CSS journey that using too generic selectors could cost us in performance – and some other problem with the cascading. In this case, it could be more than accurate because here we use the most generic selector named asterisk (*).

The asterisk selector selects every element – classes, id’s, etc. -, and because CSS is a right to the left language, it happens all the time (it happens if you give your selector a scope with a class selector like .container > * + *). Today this is no more a problem we can use it safely the browsers handle it for us in the most efficient way. Also, keep in mind if you have a large page with a massive amount of element it is nice to test this theory.

Using the Selector

Now we know what it is and where it comes from but what we can use for it? The main reason for its existence – as a wrote in the intro – is the content flow. The problem is simple, and I’m sure everybody met with it.

You want to set a standard spacing between your components/modules/anything – mostly vertically – and for this, you set a decent margin to top or bottom. After this, you face that your first or last element has unnecessary whitespace and it breaks the spacing; this is solvable with a margin overwrite on the first or last-child. But this is the best solution? Should this problem exist? If we clear this margin we also have to clear it in the other elements.

As I said I’m sure you met with this problem, and I’m sure you have a solution for it – as I have/had. Building a system with an excellent vertical flow – where you try to separate the layout from the components – can be tricky, and the lobotomized owl selector can solve this issue quickly.

Check out the following CodePen; here you can see that using * + * can solve all of our problems. Note that we used margin-top because we ignore the first element. (The third example is another solution which is also work in this context.)

See the Pen Presenting the Use of the Owl Selector by Adam Laki (@adamlaki) on CodePen.

Although it is a generic method which can handle all of your element’s margins it is nice to restrict its scope to a child or a direct child selector like so:

.container > * + * {
    margin-top: 30px;

Using this way you can nicely target your sidebar’s widgets.

Use it in Smaller Cases

Something that comes to my mind when I first met with the owl selector is the navigation styling. In this case, we often define one-way margin – depending on the navigation alignment – in li elements, and after this, we overwrite the last or the first child’s value. With this technique, we can achieve another solution.

ul > * + * {
    margin-left: 20px;

If it is overkill or not is a good question but it is not over specified and do the job.


For me, one reason why I love CSS is this type of solutions where you can get the same result with a different answer. There is no wrong or right, it all depends on the circumstances. In my opinion, this is an elegant and nonconventional way of solving the flow issue.

If you want to know more about it, please visit the original post where you can find more details.