The position property can be a mysterious thing to run into when you’re starting to learn about CSS. It’s like being given a set of unknown spices that look similar, but have very different flavours and the combinations between them don't always work like expected.
This article is an attempt to describe the best and most common pairings between them so that you can easily apply them in your first web cooking steps. Just like we learn in the kitchen — parsley goes well with garlic, but not that much with cinnamon.
First of all, let’s define what each of the position variants tastes like:
This is what every HTML element has by default. It means the element will be positioned according to the normal document flow. Block elements with full width, inline elements lining up. It’s basically the salt of them all.
Elements with relative position can be placed relatively to the space they would occupy in the normal document flow. They still occupy that space only, but support
Whatever values you assign to those properties will be used to calculate its displayed position using its real position boundaries. Like adding some pepper, it usually doesn’t do much harm.
This one’s tricky — it’s sort of like cumin, it can be a very good addition, but you have to use it carefully. Absolute elements are removed from the normal document flow. This means they don’t affect and aren’t affected by other elements in the page. However, they will be placed relatively (yes, I know, bear with me) to their nearest positioned ancestor. This means whichever parent element that has its position explicitly set. It can be fine tuned using
left too. So it’s similar to relative positioning, but, since it’s no longer part of the document flow, it uses a parent as the reference.
Ah, this one’s easy. Fixed elements are not part of the document flow at all and their position is based on the whole window, sometimes referred to as viewport. Also, they’re not affected by scrolling.
It's not advisable to use
padding when you're using
left. While the latter will offset the element's visible position the first will offset its real and document-affecting position.
Things can get confusing if you're using both on the same element so best keep 'em separated.
position: relative; whenever you want to offset an element a little bit from where it would normally be, but you don't want everything else to move with it. Remember that all other elements will behave as if it hasn’t moved. Use
left to adjust it relatively to what would have been its natural position.
position: absolute; when you care about where the element is in relation to its first parent or wrapper with an explicit (usually relative) position. Note for this that the position property does not cascade, so that's why this will use the nearest parent with an explicit position declaration, if there's none, then it will be the
<body>. If you want to force cascading of the position property, you can declare it as
Keep in mind that this element’s position is defined by the size and shape of its closest positioned parent, so if you change that, this element might be affected too.
position: fixed; is a funny thing to play around with. Normal usages include sticky navbars, footers, or side menus. Remember it’s out of the normal document flow, so this means:
- you can place it wherever you want and nothing else will break
- it also means that it won’t do anything else you don’t explicitly tell it to do, so you need to set its 2 coordinates for it to show up at all.
These 2 coordinates (namely, top or bottom, plus left or right) will be measured from the edge of the window.
(tip: scroll this up and down 👇)
There is another option I didn’t cover and that is
position: sticky;. It makes elements behave and scroll normally but then stick to a certain position while the rest of the content keeps on scrolling. I decided to leave it out, because it’s still experimental and exceeds the understand-the-basics scope of this article. But, if you’re curious, here’s an article showing what it’s all about.
I plan to address many of these basic things that I never fully understood about web development by researching them and then putting my new knowledge to the test by writing articles about it. So expect more in depth takes on basic stuff from me in the future!
Need to keep up with a fast-moving software industry?