157

I have a situation where, in normal CSS circumstances, a fixed div would be positioned exactly where it is specified (top:0px, left:0px).

This does not seem to be respected if I have a parent that has a translate3d transform. Am I not seeing something? I have tried other webkit-transform like style and transform origin options but had no luck.

I have attached a JSFiddle with an example where I would have expected the yellow box be at the top corner of the page rather than inside of the container element.

You can find below a simplified version of the fiddle:

#outer {
    position:relative; 
    -webkit-transform:translate3d(0px, 20px , 0px); 
    height: 300px; 
    border: 1px solid #5511FF; 
    padding: 10px;
    background: rgba(100,180,250, .8); 
    width: 80%;
}
#middle{
    position:relative; 
    border: 1px dotted #445511; 
    height: 300px; 
    padding: 5px;
    background: rgba(250,10,255, .6);
}
#inner {
    position: fixed; 
    top: 0px;
    box-shadow: 3px 3px 3px #333; 
    height: 20px; 
    left: 0px;
    background: rgba(200,180,80, .8); 
    margin: 5px; 
    padding: 5px;
}
<div id="container">
    Blue: Outer, <br>
    Purple: Middle<br>
    Yellow: Inner<br>
    <div id="outer"> 
        <div id="middle">
            <div id="inner">
                Inner block
            </div>
        </div>
    </div>
</div>

How can I make translate3d work with fixed-positioned children?

1

10 Answers 10

230

This is because the transform creates a new local coordinate system, as per W3C spec:

In the HTML namespace, any value other than none for the transform results in the creation of both a stacking context and a containing block. The object acts as a containing block for fixed positioned descendants.

This means that fixed positioning becomes fixed to the transformed element, rather than the viewport.

There's not currently a work-around that I'm aware of.

It is also documented on Eric Meyer's article: Un-fixing Fixed Elements with CSS Transforms.

9
  • Thanks, I hadn't noticed that the actual specification had that info..... I guess I got the equivalent to the mathematical answer: "by definition" :) Commented Mar 16, 2013 at 6:41
  • 3
    @INT, I don't think there's going to be a workaround for this. There's a major use-case for not allowing workarounds: user provided input could potentially cover controls outside of their designated area (think a malicious email adding options to the gmail toolbar). The best workaround would be to avoid transforms for the time being if you're going to use fixed from inside of it.
    – saml
    Commented Aug 26, 2013 at 15:56
  • 1
    Wouldn't setting the CSS top attribute to whatever window.scrollHeight is work? You might have to absolutely position it as well, but something like this should be doable, no? (too lazy to actually test right now)
    – Brad Orego
    Commented Jan 30, 2014 at 16:15
  • @bradorego you were right, I just added the code I used.
    – UzumakiDev
    Commented Jan 31, 2014 at 19:13
  • 1
    This is still in flux in the spec as far as I can tell. See Bug 16328 - Use of "containing block" does not match CSS2.1 definition.
    – thirdender
    Commented Dec 11, 2014 at 11:07
14

As Bradoergo suggested, just get the window scrollTop and add it to the absolute position top like:

function fix_scroll() {
  var s = $(window).scrollTop();
  var fixedTitle = $('#fixedContainer');
  fixedTitle.css('position','absolute');
  fixedTitle.css('top',s + 'px');
}fix_scroll();

$(window).on('scroll',fix_scroll);

This worked for me anyway.

4
  • 3
    It works! but instead of binding to "window", I had to bind to the div that was scrolling. Also, the fixed element flickers.
    – train
    Commented Apr 28, 2014 at 19:25
  • This could have done it, but like @train mentionned, it flickers. Commented Aug 24, 2016 at 19:36
  • Yeah, this doesn't update near fast enough to be clean enough for my usage :-/ good idea tho
    – reid
    Commented Mar 7, 2017 at 19:26
  • This is very bad practice, don't do style changes with js
    – Wannes
    Commented Feb 26, 2018 at 16:30
12

I had a flickering on my fixed top nav when items in the page were using transform, the following applied to my top nav resolved the jumping/flickering issue:

#fixedTopNav {
    position: fixed;
    top: 0;
    transform: translateZ(0);
    -webkit-transform: translateZ(0);
}

Thanks to this answer on SO

0
6

In Firefox and Safari you can use position: sticky; instead of position: fixed; but it will not work in other browsers. For that you need javascript.

4
  • 2
    Sticky positioning is a hybrid of relative and fixed positioning, and it's really experimental, I'd highly recommend to avoid this, as it's not standard yet.
    – Farside
    Commented Jul 11, 2016 at 14:17
  • 1
    AFAIK on Firefox and Safari you can simply use position:fixed and it would work as expected anyway.
    – oriadam
    Commented Sep 15, 2016 at 14:33
  • @oriadam no, I have the issue when the parent uses translate3d and children's fixed position is flying around in some cases. Will try to use sticky while it' already supported by major browsers: caniuse.com/#feat=css-sticky Commented Apr 8, 2018 at 18:18
  • sticky may be a solution,it works at modern browser.
    – aboutqx
    Commented May 17, 2018 at 9:48
3

In my opinion, the best method to deal with this is to apply the same translate, but break children that need to be fixed out of their parent (translated) element; and then apply the translate to a div inside the position: fixed wrapper.

The results look something like this (in your case):

<div style='position:relative; border: 1px solid #5511FF; 
            -webkit-transform:translate3d(0px, 20px , 0px); 
            height: 100px; width: 200px;'> 

</div>
<div style='position: fixed; top: 0px; 
            box-shadow: 3px 3px 3px #333; 
            height: 20px; left: 0px;'>
    <div style='-webkit-transform:translate3d(0px, 20px, 0px);'>
        Inner block
    </div>
</div>

JSFiddle: https://jsfiddle.net/hju4nws1/

While this may not be ideal for some use cases, typically if you're fixing a div you probably could care less about what element is its parent/where it falls in the inheritance tree in your DOM, and seems to solve most of the headache - while still allowing both translate and position: fixed to live in (relative) harmony.

0

I ran across the same problem. The only difference is that my element with 'position: fixed' had its 'top' and 'left' style properties set from JS. So I was able to apply a fix:

var oRect = oElement.getBoundingClientRect();

oRect object will contain real (relative to view port) top and left coordinates. So you can adjust your actual oElement.style.top and oElement.style.left properties.

1
  • This works on IE and Chrome, but not on Android standard browser. The left is a number but it is always drawn on the position 0
    – DATEx2
    Commented Aug 23, 2013 at 12:50
0

I have an off canvas sidebar that uses -webkit-transform: translate3d. This was preventing me from placing a fixed footer on the page. I resolved the issue by targeting a class on the html page that is added to the tag on initialization of the sidebar and then writing a css :not qualifier to state "-webkit-transform: none;" to the html tag when that class is not present on the html tag. Hope this helps someone out there with this same issue!

0

Try to apply opposite transform to the child element:

<div style='position:relative; border: 1px solid #5511FF; 
            -webkit-transform:translate3d(0px, 20px , 0px); 
            height: 100px; width: 200px;'> 
    <div style='position: fixed; top: 0px; 
                -webkit-transform:translate3d(-100%, 0px , 0px); 
                box-shadow: 3px 3px 3px #333; 
                height: 20px; left: 0px;'>
        Inner block
    </div>
</div>
0

Add a dynamic class while the element transforms.$('#elementId').addClass('transformed'). Then go on to declare in css,

.translat3d(@x, @y, @z) { 
     -webkit-transform: translate3d(@X, @y, @z); 
             transform: translate3d(@x, @y, @z);
      //All other subsidaries as -moz-transform, -o-transform and -ms-transform 
}

then

#elementId { 
      -webkit-transform: none; 
              transform: none;
}

then

.transformed {
    #elementId { 
        .translate3d(0px, 20px, 0px);
    }
}

Now position: fixed when provided with a top and z-index property values on a child element just work fine and stay fixed until the parent element transforms. When the transformation is reverted the child element pops as fixed again. This should easen the situation if you are actually using a navigation sidebar that toggles open and closes upon a click, and you have a tab-set which should stay sticky as you scroll down the page.

-1

One way to deal with this is to apply the same transform to the fixed element:

<br>
<div style='position:relative; border: 1px solid #5511FF; 
            -webkit-transform:translate3d(0px, 20px , 0px); 
            height: 100px; width: 200px;'> 
    <div style='position: fixed; top: 0px; 
                -webkit-transform:translate3d(0px, 20px , 0px); 
                box-shadow: 3px 3px 3px #333; 
                height: 20px; left: 0px;'>
        Inner block
    </div>
</div>
1
  • 1
    On IE bug does not exist in first place
    – oriadam
    Commented Sep 15, 2016 at 15:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.