Sometimes my sidebar with position: fixed scrolls with page. It happens only in Chrome. I think something wrong happening with viewport (I also have lazy loading implemented, maybe it impacts on viewport). I decided to apply transform: translateZ(0) to the sidebar element. Issue seems to be gone but I can not understand how transform impacts on elements with fixed position?
I have read a lot of information about how it works before asking this question but I can't understand how it solves the problem, maybe there's a need to fix elements which cause viewport overflow? Thanks a lot and sorry for my English.
position: fixed will always position the element relative to the initial window viewport, except when one of the element's ancestors has a transform property, in which case that ancestor behaves like the new viewport:
.container {
transform: translateZ(0); // the "new" viewport
.child {
position: fixed;
top: 1rem; // 1rem relatively to .container
}
}
So when you gave the container a transform property, it acted as the relative container to the fixed child and sorted your issue.
Check out Mozilla's CSS/position docs - they explain the subject well.
Related
Working on a website today I found myself in the position (haha...) that a logo that I wanted to fix to the viewport didn't stick anymore. In my research to resolve this problem I learned that position: fixed won't fix to viewport if the ancestor element has a transform on it (see positions-fixed-doesnt-work-when-using-webkit-transform).
I made sure not to have any transforms on my element (or it's ancestors), I even tried to remove all child elements (which happen to have transforms and animations on them) – but I still didn't manage to get things going.
I am sort of clueless right now, so I made a jsfiddle for others to look at. The element that needs fixing is the bright red .titles element: http://jsfiddle.net/ZWcD9/90/
remove transfrom from body
body {
width: 100%;
/* -webkit-transform: translateZ(0); */
/* transform: translateZ(0); */
}
I've come across a strange "bug" on Chrome where the z-index is not showing properly like in every other browser (including IE).
I've read all related questions related to it and almost everyone in their questions were missing position or overflow.
The link for the website is THIS and there is a dropdown ul element in the middle search that when you click it, is behind the pictures. I've tried for hours all possible combinations with child-parent, different z-indexes, positions and nothing seem to get the dropdown in front of the pictures.
I would really appreciate it if someone could point me in the right direction or provide a sample to help me out.
Thanks!
Solution from answers: The div element which had the problem, has around 10 div elements above it as "parents". His z-index could not get in the front because his highest parent did not have position:relative, only had z-index which caused the problem for all other child divs below it.
Here is an example:
<div> <---- had only z-index, was missing position:relative
<div>
<div>
<div> <---- this div with z-index could not get in front because of the first one
</div>
</div>
</div>
</div>
You have to add
z-index: 1000; /* or whatever value works*/
position: relative;
to your #big-map. This will fix it. You forgot to add a position to that div, which makes that a z-index doesn't get applied.
The CSS of #big-map should look like this:
#big-map {
width: 100%;
height: auto;
/* background-color: rgb(229, 227, 223); */
/* background-color: #E0E0E0; */
-webkit-transform: translateZ(0);
display: block;
z-index: 1000;
position: relative;
}
I agree with Toni Leigh though: in the future you need to share code and a working example, so this question is also value in the future. If you can't share code or set up an example with a minimum amount of code, you can always ask it in the chat, where we gladly help you with such "bugs".
This is not a bug. The fact is that z-index must be defined on the parent element as well. Basically, how is an element supposed to act if the child has a higher z-index than the parent?
The problem is on your #big-map which is the parent.
It must have a high z-index, and position relative:
z-index: 10000;
position: relative;
adding that to your #big-map will solve it.
Only solved when the z-index is added to the tag for position absolute and fixed.
<div style="z-index:110">
No matter how high the value is in CSS, chrome bug converts it to a maximum of 17.
z-index:99999999999999999999999999999999;// translates into z-index:17
Basically, I have 3 absolutely positioned elements within a relative container, one of them with left: 100% (the one coming next) and one with left: -100% (the previous picture). They transition between the available places automatically with the transition property. The final result of this can be seen here.
<div id="slideshow">
<article>
<img>
</article><article>
<img>
</article><article>
<img>
</article>
</div>
<style>
div#slideshow { position: relative; overflow: hidden }
img { width: 100%; height: auto }
article { width: 100%; position: absolute; transition: left 1s }
article.current { left: 0 }
article.prev { left: -100% }
article.next { left: 100% }
</style>
(This is the result without overflow: hidden applied, to see how the slideshow works.)
As you can see, the <img>s are responsive to their parent, <article>. I know that block elements always take the available width, so I didn't think I had to state it, but as you can see, I had to specify width: 100% on the <article>, too. What happens if I don't? Something interesting, I'd say.
The .prev <img> turns twice as big as the others, and the .next <img> renders at size 0x0. What? You clearly see that all the image should have the same dimensions: 100% width, and auto height.
What I wanted to understand is; why does the CSS work like it does? I find this result quite unexpected, so I really wanted some kind of a discussion on why the result returns what it does, so that I could better understand how the underlying components of the CSS values actually work.
Your problem is not in the images themselves, but on the article.
It's the article elements that are ruling the dimensions, and image gets the dimensions from them.
The width of the article is not set. Lacking that, and in the presence of a left statement, a value of right 0px is assumed. So, when left is 0, the width is 100% of the container, when the left is -100% the width is 200%, and when the left is 100%, the width is 0.
How to solve this ?
Add a width: 100% to article. - the direct solution.
Instead of moving the articles with the left property, do it with a transform: translateX(-100%); You won't have the problem derived from changing left, and it is more performant
Okay, so there's three ways to get browser window height (NOT full web page height, that is the difference).
Vertical height unit, explained wonderfully here.
jQuery
Using { height: 100%; position: absolute; } on an element. (jsfiddle)
I do not understand the logic behind #3 on my list.
height: 100% and absolute positioning. height: 100% fills up the parent. Positioning absolute also is relative to the parent, so shouldn't it take the full height of the page. How does the viewport come into play?
I know that fixed is relative to the viewport, but I thought that was the difference from absolute. The height: 100% div does have a parent, its the body, it should be relative to that.
Can someone please explain?
An absolutely positioned element is placed in relation to the first parent that is also positioned. The body element has no positioning applied to it in your example. Therefore, the div has no reference since absolutely positioned elements are taken out of the normal flow.
If you assign positioning to the body, typically position:relative;, you will find what you are looking for.
W3C CSS2.1 explanation
I have a DIV that must always stay on bottom/left of the page, something like a footer menu.
div#bottom_menu
{
position: absolute;
z-index: 1;
left: 0;
bottom: 0;
width: 90%;
}
My page has min-height defined and when the user shrinks it below that it gets scroll bars.
The problem is when it happens, in IE8 the div moves up to match the new viewpoint lowest point like it would behave if it were with position: fixed. Worse than that, when you scroll down again the element does not move down (like in position: fixed) but ridiculously stays in the middle of the page. This works perfectly in Firefox, Opera and Chrome. Is that a known IE bug and how to work around it?
Great, I got Tumbleweed badge for super unpopular question.
While waiting someone to help me here I solved it myself (as usual). I did it by putting bottom_menu in a wrapper div pretty similar to the old container, only difference is that is has no overflow: hidden; and is not directly inside the body. That fixed it by some strange reason. Maybe it will help somebody.