position:fixed when left/top/right/bottom aren't specified - desired results in FF/IE, but not in Safari

Question

Sorry to have to ask yet another position:fixed related question, but reading through various other questions and forum threads hasn't helped me with this one.

The code that follows is a simplified demonstration of how I have been using position:fixed in a project to date. My original (mis)understanding of position:fixed is that it initially fixes relative to the first positioned parent container, and thereafter remains in that position regardless of viewport scroll position. I now realise that is wrong: in fact, position:fixed positions relative to the outermost container (i.e. the html tag) and position:absolute positions relative to the first parent container that has a position other than static.

Reading through various other questions on SO, I realise that the effect I was trying to achieve using position:fixed is one that many other people have tried to, but then realised is not possible with just CSS: That is, to position an element relative to a container, but then have it stay where it is relative to viewport when the page is scrolled.

What confuses me though is that the above is exactly what I seemed to have achieved - at least on FF and IE8. With the code example below, the "fixed right pane content" is initially positioned to the right of the red "centre scrollable content" box, and is vertically level with the top of the centre content. The centre content can be scrolled, but the right-hand content stays where it is, as if it initially positions statically in normal document flow but thereafter remains fixed to the viewport.

I now realise that this appears to 'work' in IE8 and FF simply because I have not specified top/bottom/left/right attributes to the fixed element. If I do, then I realise that the fixed element immediately becomes positioned relative to the viewport.

I had assumed - perhaps dangerously - until now that if relative positions aren't specified, then position:fixed will by default place that element where it would normally be statically placed. At least FF and IE8 seem to be doing just that.

Testing in Safari, however, shows that Safari seems to place that fixed element to the left of its container. In other words, without positioning, my position:fixed element is neither where it would be when statically placed, nor is it positioned at 0,0 relative to the viewport.

Have I been relying on very poorly defined behaviour to date, and am I best resorting to a JavaScript solution after all to achieve this fixed positioning? Or, is this behaviour well-defined for IE / FF; and can someone explain the logic behind Safari's placement please?

<style type="text/css">
  #content-centre {
    margin: 0 auto;
    width: 900px;
  }
  
  #header {
    height: 55px;
    position: fixed;
    top: 0;
    width: 990px;
  }
  
  #left-pane {
    position: fixed;
    top: 12px;
    border: 1px green solid;
  }
  
  #main-pane {
    left: 200px;
    position: relative;
    top: 66px;
    width: 760px;
    border: 1px yellow solid;
  }
  
  #container-1 {
    border-top: 1px solid #FFFFFF;
    float: right;
    min-width: 130px;
    padding-left: 20px;
    border: 1px blue solid;
  }
  
  #container-0 {
    margin-right: 20px;
    min-height: 470px;
    overflow: auto;
    padding: 10px 0;
    position: relative;
    border: 1px red solid;
  }
  
  .side-info-list-fixer {
    position: fixed;
  }
</style>

<div id="content-centre">

  <div id="header">
  </div>

  <div id="left-pane">
    Fixed left pane content
  </div>


  <div id="main-pane">
    <div id="page-module-containers">

      <div id="container-1">
        <div class="side-info-list-fixer"> Fixed right pane content </div>
      </div>

      <div id="container-0">
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
        <p>Centre scrollable content</p>
      </div>

    </div>
  </div>

</div>

Glossotomy

To summarise the question, why does position:fixed without top or left specified not default to the top left of the window? I too am puzzled by this. – Barrera

Answer 1

I believe the answer you're looking for is as follows...

The position of an element does not default to 0,0. It's position is set by default relative to the containing element, therefor in your example, "#container-1" has a padding-left: 20px whereas the rest of the padding is set to 0 making the "default" position of the element 20px left of the wall of #container-1 and the top is 0px from the top of #container-1.

The default position of this element by default and my viewport not scrolled would be 63px from the top and the left is obviously dependent on the width of your browser. However, if you do not override the top and left, they are already defined by the rendering engine as the top:63px, left:893px.

Then on window resize, that position is adjusted to reflect the position based on the viewport so as you scroll down the position is changed to keep it fixed.

So, by simply adding "position:fixed;" your properties would (as far as the browser is concerned) be as follows:

position:fixed;
top:63px; // defined by default during browser rendering in some browsers (based on scroll position on load)
left:893px; // defined by default during browser rendering in some browsers (based on scroll position / width of browser at time of load)

Also, IE6 and the likes, do not support position:fixed at all. http://fiddle.jshell.net/uaE4g/4/show/

I hope this helps!

Series

Answer 2

I'm seeing similar results in safari 5, and not in safari 6.

across browsers, it seems to work like this:

if one of the position's properties is not defined on a fixed element, the initial value of that property is as the same as if the object was static. it seems.

after page load, it stays behaving as if it was static. so if i fix an element vertically, but not horizontally, i can scroll up and down and the element remains fixed, but if i scroll sideways the elements scrolls along with the page.

but in safari 5, if the element is within an container that has positioning, it seems to behave as you describe: the initial value is the same as if it were static, but afterwards it remains fixed on that position.

your 'side-info-list-fixer' is within 'main-pane', which has position:relative. take that off and you might see the same behaviour as in safari 6 and most other browsers.

i dont know whats correct and wether you should depend on these features ...

$2c, *-pike

Articulation

Answer 3

I had the same requirement, to position an element fixed at it's natural (default) static position with relation to the viewport. I ended up using this simple jQuery function.

function SetFixedPositioning(element) {
    var currentOffset = $(element).offset();
    $(element).css("position", "fixed");
    $(element).offset(currentOffset);           
}

Use it like this:

SetFixedPosition($("#element-to-position"));

My use case was a second level navigation menu that flowed into the document, then was fixed at that position.

Interstadial