As per the title, it seems only Chrome isn't playign along. Note that form fields cannot be clicked on which are on the left portion of the screen. This only occurs on some pages (such as the Contact page). It appears that the #left_outer div is overlaying the content. When I edit the css via Firebug or Chrome's dev toools, it works, when I edit the actual css and refresh, it does not.
Any ideas?
LINK:
Thanks!
Usually when you have set the z-index property, but things aren't working as you might expect, it is related to the position attribute.
In order for z-index to work properly, the element needs to be "positioned". This means that it must have the position attribute set to one of absolute, relative, or fixed.
Note that your element will also be positioned relative to the first ancestor that is positioned if you use position: absolute and top, left, right, bottom, etc.
Without a link to look at, it's a bit tough to see what the problem might be.
Do you have a z-index: -1; anywhere (a negative number is the key here, doesn't matter the number)?
I have found in the past this renders the container void from being interacted with.
Good luck!
Markt's answer (see first answer) is great and this is the "by definition" of the z-index property.
Chrome's specific issue are usually related to the overflow property from the top container bottom.
So, for the following:
<div class="first-container">...</div>
<div class="second-container">
<div ...>
<div class="fixed-div> some text</div>
<... /div>
</div>
And styles:
.first-container {
position:relative;
z-index: 100;
width: 100%;
height: 10%;
}
.second-container {
position:relative;
z-index: 1000;
width: 100%;
height: 90%;
overflow: auto;
}
.fixed-div {
position: fixed;
z-index: 10000;
height: 110%;
}
the following actually happens (Chrome only, firefox works as expected)
The 'fixed-div' is behind the 'first-container', even though both 'fixed-div' and its container's ('second-container') z-index value is greater than 'first-container'.
The reason for this is Chrome always enforce boundaries within a container that enforces overflow even though one of its successors might have a fixed position.
I guess you can find a twisted logic for that... I can't - since the only reason for using fixed position is to enable 'on-top-of-everything' behavior.
So bug it is...
I had a weird issue with zIndex on Chrome and I kept fiddling with the position attribute to see if anything worked. But, it didn't. Turns out, in my case, the issue was with the transform attribute. So, if you have a transform attribute in place, disable it and it should be fine. Other browsers work fine with stuff like that, but Chrome seems to play it differently.
Hope this helped you.
Google Chrome to 84.0.4147.135 (Official Build) (64-bit) 2020-02-22.
Since my last update, CSS element z-index is broken in Chrome.
Chrome added "z-index: 1;" to the BODY element.
It now wrongly displays all z-index: ?; values in the BODY child elements.
Setting the position, z-index of BODY does not solve the problem.
Changing z-index values of child elements that were already correct does not help.
I hope this issue will be fixed, it is only broken since I updated Chrome.
Chrome 84.0.4147.135 bug on www.eatme.pro/music - screen smaller than 500 px - push play - appearing bottom bar #lblBottomBarLink with z-index 5 is displayed under menu with z-index 2
(see image)
image eatme.pro/music in Chrome 84.0.4147.135 with z-index 5 under z-index 2
I know this is now resolved but posted solution didn't work for me. Here is what resolved my problem:
<act:AutoCompleteExtender ID="ace" runat="server" OnClientShown="clientShown">
</act:AutoCompleteExtender>
<script language="javascript" type="text/javascript">
function clientShown(ctl, args) {
ctl._completionListElement.style.zIndex = 99999;
}
</script>
Related
I can't seem to get z-index work on bootstrap popover if it's in div which has smooth div scroll on it. I've tried putting extremely high values, looked in all css's to see if there were any z-indexes higher then popover's but achieved no success.
Javascript:
$(".project").smoothDivScroll({
mousewheelScrolling: "allDirections",
hotSpotScrolling: false,
touchScrolling: true
});
$(".block").popover({
html: true,
animation: true,
placement: 'right'
});
Here's how it looks at the moment: 1, 2.
Live example: here
This is old, but for others, try adding the following attribute:
data-container="body"
The clipping you are seeing is probably not related to z-index declarations but instead related to the size of your .project div and the overflow declaration for a nested div.
div.scrollWrapper {
position: relative;
overflow: hidden;
width: 100%;
height: 100%;
}
The overflow:hidden; is what's creating the clips you're seeing.
I believe it has something to do with your overflow. It seems to be clipping your boxes. If you look at .scrollWrapper in smoothDivScroll.css and change overflow to visible, you will see a bit more of our box. I know this isn't your desired effect, but I think it's a start. Has to be something with your overflow.
# the mad zergling
I have an popover that pops automatically on page load and gets hidden automatically after some timeout (in the reality it gets destroyed), it is indicating a brief instruction on/about the navbar itself. I also do use scrollto.
I've tried adding
data-container="body"
no way, the behaviour is for the mobiles and depends on that mobile device and its browser.
On blackberry OS 10 it behaves as expected, popover is on top of everything and it was not needed the data-container (though it could be helpful for other devices)
On samsung/android the default browser doesn't show the popover, though also some html5 circles are displayed as squares, so looks it is neither html5 capable, also the dropdown items are not fully displayed, a total scrap.
On the same samsung/android, firefox is much more better but there, the popover is hidden by the navbar logo. Not tried chrome for android.
I expect it will be its own story for every mobile browser on each particular device.
When scrolling on a website I've built, using the CSS property position: fixed works as expected to keep a navigation bar at the very top of the page.
In Chrome, however, if you use the links in the navigation bar it sometimes disappears. Usually, the item you've clicked on is still visible, but not always. Sometimes the entire thing disappears. Moving the mouse around brings back part of the element, and scrolling with the scroll wheel or arrow keys just one click brings the element back. You can see it happening (intermittently) on https://nikeplusphp.charanj.it - you might have to click on a few of the navigation the links a few times to see it happen.
I've also tried playing with the z-index and the visibility/display type but with no luck.
I came across this question but the fix didn't work for me at all. Seems to be a webkit issue as IE and Firefox work just fine.
Is this a known issue or is there a fix to keep fixed elements visible?
Update:
Only effects elements that have top: 0;, I tried bottom: 0; and that works as expected.
Add -webkit-transform: translateZ(0) to the position: fixed element. This forces Chrome to use hardware acceleration to continuously paint the fixed element and avoid this bizarre behavior.
I created a Chrome bug for this https://bugs.chromium.org/p/chromium/issues/detail?id=288747. Please star it so this can get some attention.
This fixes it for me:
html, body {height:100%;overflow:auto}
I was having the same issue with Chrome, it seems to be a bug that occurs when there is too much going on inside the page, I was able to fix it by adding the following transform code to the fixed position element, (transform: translateZ(0);-webkit-transform: translateZ(0);) that forces the browser to use hardware acceleration to access the device’s graphical processing unit (GPU) to make pixels fly. Web applications, on the other hand, run in the context of the browser, which lets the software do most (if not all) of the rendering, resulting in less horsepower for transitions. But the Web has been catching up, and most browser vendors now provide graphical hardware acceleration by means of particular CSS rules.
Using -webkit-transform: translate3d(0,0,0); will kick the GPU into action for the CSS transitions, making them smoother (higher FPS).
Note: translate3d(0,0,0) does nothing in terms of what you see. it moves the object by 0px in x,y and z axis. It's only a technique to force the hardware acceleration.
#element {
position: fixed;
background: white;
border-bottom: 2px solid #eaeaea;
width: 100%;
left: 0;
top: 0;
z-index: 9994;
height: 80px;
/* MAGIC HAPPENS HERE */
transform: translateZ(0);
-webkit-transform: translateZ(0);
}
The options above were not working for me until I mixed two of the solutions provided.
By adding the following to the fixed element, it worked. Basically z-index was also needed for me:
-webkit-transform: translateZ(0);
z-index: 1000;
This is a webkit issue that has yet to be resolved, oddly making the jump with JavaScript, rather than using the # url value, doesn't cause the problem. To overcome the issue, I supplied a JavaScript version that takes the anchor value and finds the absolute position of the element with that ID and jump to that:
var elements = document.getElementsByTagName('a');
for(var i = 1; i < elements.length; i++) {
elements[i].onclick = function() {
var hash = this.hash.substr(1),
elementTop = document.getElementById(hash).offsetTop;
window.scrollTo(0, elementTop + 125);
window.location.hash = '';
return false;
}
}
I could refine this further and make it is that only it only looks for links beginning with a #, rather than ever a tag it finds.
If it don't work after adding
-webkit-transform: translateZ(0)
than also add
user-scalable=no
on viewport meta
source here
it worked for me
I encountered the same issue in a different case. It was because of usage of same id in multiple place. For example i used #full 2 divs.
It seems that mozilla and I.E. supports usage of same id in multiple cases. But chrome doesnot. It reacted with fixed element disappering in my case.
Just removing the id's solved the problem.
None of them worked for me except calling the modal via javascript
Click me to open MyModal
<script>
function show_modal()
{
MyModal.style.display = 'block';
}
</script>
other than this, none of the solutions above solved my problem.
This Worked for me . Add Overflow property to your top most container which can be Div or Form etc.
div, form
{
overflow:visible;
}
The same issue happened to me. For the main page of the website. I made a fixed header and Used an image for the front poster. Everything worked fine. But the moment I changed the opacity of the poster image my header with position: fixed; got disappeared. It was present there in the chrome developer tools. But was totally transparent on the website.
I tried every solution from StackOverflow, W3shools, Geeke4geeks. But if one thing was fixed another thing got messed up.
So I just opened photoshop and edited the image manually. And then posted it on my website.
It worked.
But still, it won't be effective for divs under the fixed elements.
If none of the answers above worked for you, make sure you aren't a dummy like me and have overflow: hidden; set on the fixed element :(
What if none of above worked at all? simple case of sticky header + mobile side menu pushing content.
I try to find a way to avoid fixed element (sticky header) being translated but in this case nothing is a good alternative.
So as there is no workaround on scope so far there is a JS alternative that I opted for to recalculate absolute position of fixed element. See here: https://stackoverflow.com/a/21487975/2012407
In my case, I just added min-height: 100vh; to fixed element, may be that will be useful for somebody
iOS 5 released web designers a new property -webkit-overflow-scrolling:touch that uses the iOS devices hardware accelerator to provide native scrolling for a scrollable div.
When implemented on our site in development it does work but not well. I believe there may be a CSS issue hence I ask here.
The following fiddle will show you it working perfectly
If you pop over to our site in development you will find the same panel under facilities tab but on iOS although the scrolling is perfect the overflowed section is not shown with pictures literarily chopped in two.
http://www.golfbrowser.com/courses/mill-ride/
I have no idea how to fix this
http://www.golfbrowser.com/photo.PNG
As #relluf pointed out, applying 3D transitions on the relative element fixes the bug. However, I investigated it a bit further and it seems that applying -webkit-transform: translateZ(0px) works too (this is what Google does on gmaps map container) and it does not need to be on the relatively positioned element, just the direct descendant of the scrollable element.
So if you don't want to manually keep a list of all the places where the fix is needed, you just might do:
element {
-webkit-overflow-scrolling: touch;
}
element > * {
-webkit-transform: translateZ(0px);
}
What a bugger they let loose here. Tried all manner of workarounds until I finally found the only property needed by for elements to be properly rendered in a -webkit-overflow-scrolling:touch div: position: static
Relative and absolute positioned elements are always cut off on the boundary, and completely missing (except for empty space) outside of it. If you change the position property dynamically, from static to absolute, only the visible portion of the scrollable div viewport stays rendered, wherever the offset happens to be.
I have run into this bug as well. I fixed it by applying the following css to parent elements:
-webkit-transform: translate3d(0, 0, 0);
However, I have noticed that that slows down rendering and might select other input elements than wanted when a touched input element is scrolled into the center of the view (by Safari/iOS).
In iOS, when an element inside an element with -webkit-overflow-scrolling: touch set is positioned absolutely (or fixed) relative to an element outside of the scrolling container, the element is rendered only once and the rendering is not updated as the element is scrolled. Sample HTML:
<div class="relative-to-me">
<div class="scrollable">
<div class="absolutely-positioned">
</div>
</div>
</div>
If you force a re-render by changing a CSS property (in the inspector for example), you can see that the element's positioning is re-rendered into the correct location. I suspect this is a result of some performance features to optimize scrolling performance.
The solution to this problem is to set will-change: transform on the absolutely (or fixed) positioned element.
.absolutely-positioned {
will-change: transform;
}
I deeply investigated this bug, I also created a jsfiddle and submitted it to Apple in a bug report. Please see: iOS5 Images disappear when scrolling with webkit-overflow-scrolling: touch
As soon as Apple replies to me, I'll report it on that topic so you can stay up-to-date about this very annoying bug
I also experienced the problem where overflow scroll with -webkit-overlfow-scrolling set to touch resulted in redraw problems with positioned elements. In my case I had a list where the individual items had relative positioning so that I could use positioning on their child elements. With the above CSS on iOS 5, when the user scrolled hidden content into view, there was a momentary delay before it redrew the screen to review the elements. It was really annoying. Fortunately I discover that if I gave the parent node position relative as well, this was resolved.
The bug still lives in iOS 6. If your issue is related to position: relative, you might solve the issue be setting z-index: 1 temporarily via JS. -webkit-transform: translate(...) did not work with position: relative in my case.
I tried some different solutions, seemed not work perfectly in my case.
Finally I've found a way works fine with jQuery:
Apply -webkit-overflow-scrolling property every time when you touch up.
*At first I Applied Also -webkit-overflow-scrolling:auto when TouchDown, to disable iOS rendering. But it made Page blink. So I dropped it away, then works fine surprisingly!
Check lines below, hope it helps:
<!-- 🍉 JQuery Functions-->
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js"></script>
<script type="text/javascript">
//🍋 Apply -webkit-overflow-scrolling in Every TouchEnd
$(document).on('click touchend', function(event) {
$("#TestDIV").css({"-webkit-overflow-scrolling":"touch"});
});
</script>
<!-- 🍉 html Elements & Style -->
<div id="TestDIV">
<div class="Element"></div>
<div class="Element"></div>
<div class="Element"></div>
<div class="Element"></div>
<div class="Element"></div>
</div>
<style>
#TestDIV{
white-space: nowrap;
overflow-x: scroll;
-webkit-overflow-scrolling:touch;
}
#TestDIV .Element{
width:300px;
height:300px;
margin: 2px;
background-color: gray;
display: inline-block;
}
#TestDIV .Element:nth-child(odd){
background-color: whitesmoke;
}
</style>
I have this code, which is behaving differently in firefox vs chrome.
<h2>Presenting
<span style="font-weight:bold">Analytics by </span>
<div class="fi_logo"><img src="IMAGEURL" /></div>
</h2>
the class fi_logo referenced above is :
.fi_logo {
min-width: 35px;
height: 35px;
margin-left: 40px;
position: absolute;
top:-5px;
left: 262px;
float:right;
}
In firefox, there is an offset caused by margin-left in fi_logo between the image and the text(in h2). If i dont add the margin-left, then the image overlaps the text in chrome.
So, in short, if i add the margin-left property, it works in chrome, whereas it causes a large offset in firefox. Any suggestions on how to solve this?
Here it is: http://jsfiddle.net/bikerabhinav/mpL79/2/
Use combination of position relative and absolute.
Also, do not use div inside h2 - bad markup
Maybe if you set .fi_logo display:block
I think, your problem is with specific browser version.
I checked it in FF 3.6.2, which return same result like Chrome
Well it sounds like you still haven't sorted this out so I will make a little more commentary.
I cannot say exactly what is causing the browser inconsistencies without doing a bunch of trial and error, but I think that the way to fix it is to rethink the way you are positioning the image.
It seems awful convoluted to be positioning the img absolutely, floating it, and adding a left margin. Given all of that it is unclear what precisely you are even trying to accomplish with this code.
If you edit your question to describe how you want the image positioned, I (or someone else) would be more than happy to recommend a good approach
Your html is invalid. You cannot have a div inside a heading. I also question the float and absolute positioning on the same element. I also wonder if you are using a doctype.
Your image tag inside the div is not closed properly, and in the css the class definition is wrong; the class is defined by a dot (.);
Ok, I'm stumped!
If anyone has a suggestion or two on a CSS / JavaScript fix for an IE7 z-index issue on this page without changing the DOM structure much (it's set up for easy tab usage) I'd be incredibly happy to try it out.
On this page, IE7 renders the bar that spans 100% of the width of the page above everything else, while I actually need to cram it very specifically between the text and the hero image (as seen when viewed on any modern browser).
Here's the link.
Thanks.
IE7 has known bugs with z-index, see: IE7 Z-Index issue - Context Menu
In this specific instance, you can fix it by changing a few parts of your CSS. Complete each step and check the progress as you go:
On #container remove position:relative .
The z-index issue is now fixed, but everything is in the wrong position!
On #thumbnails and .pane_img remove these properties: position, top, left, z-index.
On .pane_content, set left:50%; margin-left:-480px; bottom:90px.
On #learn_more_btn and .renova_logo, repeat the left: 50%; margin-left: ??px method to place the elements back where they should be.