All elements in all browsers start out with the default positioning value static
. You’ll rarely see this in an actual stylesheet, so the word might not be all that familiar. It’s just as well, the word itself isn’t very helpful in understanding what it means. You might think it makes the element sticky like when you rub a balloon on your head and stick it to the wall (static electricity). Really, it means the element will fall into the flow of the document as it normally would, unlike other positioning values which can remove the element from the natural document flow.
Now let’s say you take some element in its default static state and make it position: relative;
. What happens? Just by changing/setting that value alone, nothing happens. It appears in the exact same place that it did before the change. What does change is these three things:
- You can now nudge the position of the element with top/right/bottom/left values. However it’s original location will still be occupied by the element (like there is a ghost of the original element still there taking up space).
- The element will now honor the z-index property, which controls which elements should appear on top in the case of overlap.
- If the element has child elements that are absolutely positioned, they are now absolutely positioned within the context of this element.
So relative positioning enables some features and properties, but doesn’t do much on it’s own. So what if all elements just started out as position: relative;
, rather than position: static;
?
Advantages
If all elements started out with relative positioning, all three of the items above you’d have naturally. Your top/right/bottom/left values work as you would assume they do right out of the box. Z-index “just works” as well. The positioning context is always constrained to the next parent element, which makes logical sense.
I think overall CSS gets a understandability upgrade.
Disadvantages
Most notably, always constraining the positioning context to the parent element is limiting. Let’s say you want to position an element in the upper right of the page regardless of where the element appears in the markup. That’s going to be tough if the element is buried down the hierarchy. You’ll need to reset that positioning context for every parent element. That means setting them back to position: static;
, and losing all the benefits of relative positioning along the way. =(
If natural relative position ever became a thing, I would think we’d need a different way of handling positioning contexts. Possibly like:
/* Not real code */
#parent-element {
context: inherit | pass | accept;
}
Doing it today
Would mean:
* {
position: relative;
}
So…
It’s probably not going to happen. This would be a pretty nasty breaking change with limited/questionable benefits. It’s also hard to say which we would end up doing more on average: setting position relative or resetting positioning contexts. I just think it’s an interesting thing to think about.
This is a fun thought. It would eliminate most questions about z-index not working as you said, I know it would have saved me some time wondering why some things weren’t working when I first started web design. It would be interesting to try to code a site like that.
I hope I misunderstood you, but wouldn’t position: absolute still position something in upper right of the page?
no it would position it, in the upper right parent element corner
.abs{
position: absolute;
right: 0px;
top: 0px;
z-index: 999;}
{div style=”position: relative”}
{div style=”position: relative”}
{div style=”position: relative”}
{div style=”position: relative”}
{div style=”position: static”}
{div class=”abs” }
{/div (X6)}
This can do it? Right?
I didn’t read the spec but would it be allowed to ask what <position: fixed;&rt; is for?
I remember it being used for such purposes… or is there a difference from ‘absolute’?
@ danieldalu position fixed, attaches the element to the browser window. This means
.fixed {position:fixed; top:0; right:0;
}Would always appear in the top right of the window, even when the user scrolls.
@danieldalu
I agree with Jonathan fixed position, will hold the element stay on top even the mouse scroll you can see the top bar of stackoverflow website
This article made me to take another look at http://www.w3.org/TR/CSS2/visuren.html#propdef-position
The definition of position:relative is not as clear as three things that you have mentioned. Its like saying that CSS was created to make people guessing what would every CSS property do and figure things out by themselves.
I actually like that about CSS. It constantly reminds me of how I started doing HTML when I was 12 and still learn how to program new languages. It’s also really fun to find new things about CSS and the DOM every day I fiddle with it. It’s like a magical treasure box with no bottom.
interesting thought
position: fixed will probably bypass relative parents if this is your concern. Of course, you might not want the item to stay stuck to the viewport like that.
On most mobile WebKit browsers (Android, iOS), you even get the benefit(?) that fixed behaves identically to absolute, due to the way the viewport is implemented. (This drives me mad, BTW). :P
You could also use JavaScript to move items out of their relative parents if you wanted to both have your semantic mark-up cake and eat it.
Very interesting discussion. I think this points out a flaw with z-index.
Thanks Chris. When I was first learning CSS, this really tripped me up. “Why do I need position: relative?” So you can absolutely position child elements and use z-index. “Ok…so why can’t I do that by default?”
Your insights are appreciated.
I rather do this:
* {position:relative;}
and the later, if needed declare ‘position: static’ to the parent, or ‘z-index:99’…
Untested idea: if you wanted to access an “absolute to window position inside a relative positioned parent” theory, couldn’t you just remove the element with javascript and then reattach it to the body instead? Would the styling remain or would this too need to be cleared and then re-applied?
It’s 12:36am here and I could be thinking about this whole thing wrong but thanks for the article Chris, and the sleepless night now everyone else! ;-)
Goodnight … I hope!
yeah i do that too….
I rather do this:
and the later, if needed declare
position: static
to the parent, orz-index:99
…I have been using this to start my projects:
div,ul,li { position:relative; }
If some other element needs to be set to relative I do that manually.
What’s the little smiley face / frowny face icons above this thread? Are they supposed to do something?
I like to position things NOT based on the order they appear in the markup. It seems arbitrary for the line-number in the html to affect the page layout. So yes, I’ll stick with setting position: relative as a deliberate request to leave static positioning.
Or maybe it’s just what I’m used to doing. It’s an interesting thing to ponder. Something you only find here on css-tricks.
Now that I’m leaving a comment, it occurs to me you used to use Intense Debate, or Disqus for your comments. Why did you go back to WP comments? Just curious.
I believe they’re for “Featured” and “Buried” comments, respectively.
Yeah, I though about it before, after get annoyed by declarind position:relative to 90% of my block elements, on every site.
I personally think its all personal opinion, I for one rarely use position absolute to position something way outside the bounds of its parent div so having all divs set to Position: relative by default would be a time saver for me.
Having said that, I realise that there are other people who would have more problems with this than I do. so meh, to each their own.
I started out using
* {position:relative;}
but I found that it caused problems in older browsers (specifically, IE6 would no longer scroll… at all.)
Since then, I started using
body * {position: relative;}
Keeping the html tag static seemed to increase cross-browser compatibility greatly.
Had this been the original spec, we’d all be used to it, but as has been previously mentioned, positioning something to the top left of the screen would be a far harder task than it needs to be and in a way, the current spec does take care of nearly every scenario… it wouldn’t be unfeasable to provide, like Anna suggested, :
body * { position: relative; }
to get this into your code.
I’m not a fan of reset stylesheets myself, so wouldn’t do this, but I could see where this could have benefits…. If only to stop * { float: left; } appearing in stylesheets! *shudders*
Watch out for those IE bugs ! Having position relative inside a overflow : auto turns it into fixed and when float meets a relative div sometimes you get a peekaboo bug!
Interesting idea. I like it because I think that having an element appear in the layout without any respect to it’s parent is quite confusing. e.g. if you have no non static ancestors a position:absolute element is positioned relative (confusing term) to the body. Thus it’s location in the DOM actually doesn’t matter, you could make it a direct child of the body or you could nest it as deeply as you like.
I have thought of it as best practice to place an absolutely positioned block as a direct child of the node used to establish it’s positioning context. Maybe others do not agree, but this idea would encourage the same so i give it a thumbs up.
For me using “position: relative” is not necessary, because things must be always simple.
Nice concept.
Lets say we have a system where all elements get position:relative by default.
We cannot place a child element to top left of the page with position:absolute as its position is limited to the parent elements boundaries by default.
What is we could add a behavior to all elements that if position:static is applied to the child elements – they can then break free from the relative cage for all parent elements!
what say?
Imagine there’s no static, it’s easy if you try. No s below us, above us, only {style}s.
Meant to day ‘divs below us’, but it disappeared.
.pos{position:relative}
never distorts the design, this doesn’t disturb when not needed also.So we can use this always, may in place of
.pos{position:static}
also..pos{position:fixed}
is having it’s own importance. There is no replacement for this (as I know).There is a simpler version (of code). It is easier to get I hope.
http://cl.ly/05272M0M1O3s370V1J3q
Yeah that’s totally easier to understand =)
I think my problem was that I didn’t think to insert the audio elements right into the menu items until later, so I had all that junk about saving a reference with data, so theoretically you could just append them to the body and they’ll still work.
hmm very interesting. Thx! I am gonna use this for our website! Bookmarked your place!
Awesome article, I’ve been designing sites on / off for about 5 years, took it up again properly about 2 months ago, done about half a dozen sites since then, just doing one now, and i spent about two hors playing around with the position: tag of each of the elements to see what they did etc, it’s difficult to remember in what order things to go, as in; absolute into relative or relative into absolute, etc, well I always get confused anyway!
Well I really like your site, it’s so informative and I’ve learnt so much from it!
Ashley
I personally think its all personal opinion, I for one rarely use position absolute to position something way outside the bounds of its parent div so having all divs set to Position: relative by default would be a time saver for me.
Instead of making
position: relative
the default case, it would be better if we could apply z-index for even theposition: static
elements. This way, we are getting the benefit of z-index while still avoiding to resetting the positioning contexts, if the default values were to beposition: relative