i know this issue is well documented but i cant find a working solution from what ive been reading. I have a pretty large site and i want a div to sit ontop of everything else on the site. now ive tried giving the div "position:absolute; z-index:99999;", this will work in everything apart from ie. How can i do this in ie?
You can try:
position: fixed; z-index: 9999;
This will make the div to appear on top of the others. (and follow as you scroll down)
so i tried this jquery script i found
$(function () {
var zIndexNumber = 1000;
$('div').each(function () {
$(this).css('zIndex', zIndexNumber);
zIndexNumber -= 10;
});
});
i added another wrapper around it to check if the broswer is ie before hand. this seems to fix the issue but does mean pages are slower loading in ie as every div is being treated. when the page loads.
This isn't what should happen. Without seeing the HTML & CSS, it's difficult to identify why. Some standard debugging techniques...
Setting the z-index to a very high number should render that element in front of everything else**. If it's not being rendered in front, then something is setting the z-index of the other elements to something higher. This could be set in CSS or by script. The quick check is to turn off scripting. To investigate this, use firebug to find the z-index of the element in front. To find it, edit any scripts, even minified ones, and simply search for "z-index".
It sounds like a quick "back to basics" re-examination of the problem may yeild the cause.
Normally one would use low z-index numbers - 2 is higher than 1, why use more?!? Some plug-in developers have been known to use stupidly high z-index numbers.
.
** IE 6 has a well-known bug where replaced form elements (e.g. select) will 'shine' through. The fix is to put an iframe in front of it.
Related
507 pages are being printed even though there are only 9 pages of content (498 blank pages)
Dearest community, after one of the latest releases of chrome, somewhere after version ~103-105, an unfortunate bug appears when printing a web page.
It either prints hundreds of blank pages and/or prints distorted proportions outputs.
This change applies to all chromium based browsers (Google Chrome, MS Edge...),
and occurs especially in pages with charts or graphs.
If anyone else encountered this issue - the reason lies in the CSS property "position: absolute".
If your code posseses "position: absolute" you may want to change it to "fixed" or "relative", depending on your needs.
My code needed 2 changes. One required massive refactoring since changing the position property enforced me to recalculate lots of other elements.
The second took only 3 lines of code but alot longer to find since it made me override "Charts.js" internal CSS styling and implemented the "!important" flag, like so (my app uses chartjs version 2.9.4):
.chartjs-size-monitor-expand > div {
position: fixed !important; // cannot stay "absolute"
}
The "position: absolute" property appears in 3 other classes, so if the above suggestion does not suffice - you may want to try the following (or locate other places containing absolute position):
.chartjs-size-monitor,
.chartjs-size-monitor-shrink,
.chartjs-size-monitor-expand,
.chartjs-size-monitor-expand > div {
position: fixed !important; // cannot stay "absolute"
}
Hope this helps. Good luck.
Same problem here, also using ChartJS. Thanks for posting your solution, it is working for us. Note there is an open Chromium issue about this.
I had the same problem, it printed exactly 420 blank pages more. I just added this to my custom css file:
.chartjs-size-monitor-expand > div { position: fixed !important; }
I've followed the tutorial url to get a popup working:
I have one caveat though. Sometimes the pages it will be popping up from are really, really long. The code in the tutorial has it popping up in the center. Vertically, this is not acceptable. I'm trying to get it to pop up in the center, but at the very top. I've used top: 0px; and for testing purposes left: 0px; (and a few others) but it seems to matter not. Always pops up in the center.
You can take a look at the latest one I've done here
Am I missing something?
Your technique is very old and not the right way!
What happens in your case is, you have considered the page's height and width for calculating the center position. If you can change it like:
popUpDiv.style.top = '10%';
Just give a try and let me know.
Best Suggestion: Use jQuery! :)
But, what I have followed is from Queness, which is still more simple.
Tutorial: Simple jQuery Modal Window Tutorial and Live Demo.
Hope it helps! :)
In your css for #popUpDiv do top : 0 !important and you will find your popup box at the top. It is because javascript is calculating the top position and its overwriting your css style. Hope this helps.
The problem is your top and left values are being ignored in the CSS because whatever script you're using to make the popup happen is applying the styles inline directly to the popup. So you should look through that script and find where it's applying the styles, then change it there.
I've been experiencing an issue in mobile versions of webkit (specifically Webkit 534.46 on iOS 5.1.1 as mobile Safari, and now Chrome for iOS) which doesn't happen on any desktop browser that I've seen. (i.e. the demos below should be viewed on a mobile version of webkit.)
Here is a live example of the issue. The core of the CSS is extremely straight forward. It positions an alphabet index along the left of the page:
#index {
left:0; margin:0; padding:0; position:fixed; top:0; width:3em;
}
The issue happens when an element is fixed position over the top of the body. It is fully able to be interacted with until the scroll changes and then it stops accepting input. If I (manually) jiggle the scroll even one pixel then it becomes active again. The example was kept as simple as possible and does not use any JavaScript. After really hammering on it, I've discovered that it appears that the element thinks it is scrolled but has been visually fixed. In other words, if you click on 'A' then try to click on 'A' again, sometimes you will get a second click in but it will be further down the list. This seemed like a CSS reflow issue to me. I know that mobile webkit attempts to reduce the number of reflows.
Here is a live example of the workaround.
I am able to use JS to force the CSS of the entire document to reflow on scroll (with a throttle which prevents it from happening until 100ms after scrolling) which seems to workaround this issue in the simple example. Unfortunately, this does not help the real world version of this issue.
This is the code for the issue page and the workaround script.
My question is what is happening here and is there a CSS workaround that I am missing? Specifically, I'm curious if any CSS guru can figure out what the layout situation is that prevents the clicks from hitting the correct place on the fixed element? A better understanding might help find a real fix.
Edit: I forgot to mention that the example explicitly forces the viewport to the size of the window. So the user cannot zoom in/out, meaning that the position:fixed should anchor the element to the left side of the window.
Update (2012-09-20): This appears to be fixed in Mobile Safari on iOS 6 (as well as UIWebView). Any workaround should first check to make sure it is on iOS < 6. For example, using CssUserAgent this would look like:
if (parseFloat(cssua.ua.ios) < 6) { /* ... */ }
The answer that actually solved my particular issue was a variation of a solution found in one of #Paul Sweatte's links:
Essentially, a plain div which is taller than the body is added. When it is removed, it causes the body to effectively scroll or reflow. Setting the delay to 0ms between adding/removing is enough to allow the DOM to recalculate without causing any flickering. This was the minimal script I could find which fully solved the problem for all position:fixed elements on my particular instance of this issue.
var hack = document.createElement("div");
hack.style.height = "101%";
document.body.appendChild(hack);
setTimeout(function(){
document.body.removeChild(hack);
hack = null;
}, 0);
Ironically, my original reflow fix (linked to in the question) is now working in my real app, too. Putting a variant of it here in case is useful to anyone else. It can be called on any container element, or if nothing is passed in it reflows the whole document.
var forceReflow = function(elem){
elem = elem || document.documentElement;
// force a reflow by increasing size 1px
var width = elem.style.width,
px = elem.offsetWidth+1;
elem.style.width = px+'px';
setTimeout(function(){
// undo resize, unfortunately forces another reflow
elem.style.width = width;
elem = null;
}, 0);
};
The nice thing about this is that it doesn't require creating / adding / removing elements, just tweaking the container.
My install of iWebInspector is pretty busted right now, but after messing around with jsfiddle and the iOS sim it seems like your hunch is correct - despite being position:fixed, the browser thinks the page has scrolled, and screws up the click targets.
It looks a lot like this is the same issue as iOS Safari: Anchors within a fixed positioned element only work once, which also hasn't been solved with pure CSS. Also related: Fixed position navbar only clickable once in Mobile Safari on iOS5.
Tangentially, and I'm sure it's been noticed already, it's not possible to scroll the left side, so on an iPhone the index only shows A-M.
Looks like this is a known bug:
the core problem is: if the page moves programatically (i.e. the user didn’t cause the scroll) the elements inside the fix element are unavailable.
Use absolute positioning, change the markup, or use one of the hybrid workarounds.
Here's a variation of McKamey's workaround. It avoids reflowing twice, and may help with flickering (depending on your app):
setTimeout(function(){
document.body.style.borderBottom =
document.body.style.borderBottom === 'none' ? '1px solid white' : 'none';
}, 0);
I believe this is better, and achieves the same effect, allowing links to be clickable in fixed footers. Somehow, doing urlbar hiding causes links in the fixed footer to be unclickable until you scroll a little bit. I have seen this too when focusing inputs, and I attach an event handler to all focus events to fire this off as well. I do this with dojo to attach the events.
if(navigator.userAgent.match(/iPhone/i)){
/* The famous iOS can't-click-links until touch fix, I attach onfocus */
query('input,textarea,select', this.domNode).on('focus', function(el){
document.documentElement.style.paddingRight = '1px';
setTimeout(function () {
document.documentElement.style.paddingRight = '';
}, 0);
});
}
I have a google map built from the Google Maps API v.3 on a website that I am building. It works fine in all browsers. However, in Safari (for the Mac at least) it is affecting other elements in an odd way. It seems to really only apply to absolutely positioned elements and it may have something to do with z-index. Has anyone had any experience with something like this? What did your solution end up being? Sorry I cannot post a URL yet.
Thanks!!
I ended up finding the solution to my problem. It did indeed have to do with z-index. Interesting that it was only happening in Safari, though. Regardless, if anyone else is noticing something odd going on with Safari and google maps it may have something to do with the z-index of an element on your page. That's where I would start. Thanks again!
The solution that worked for me here (as -webkit-transform:none; stops maps and other functions working on a page), was to ajax in the content via jQuery after load.
Hope that helps!
I'm not completely certain what's going on there since you aren't able to post a sample URL, but if nothing is working after you've tried everything, you can report the issue to the Google Maps API team and they can more thoroughly investigate to see what the issue is.
This is indeed a bug, and is not specifically on Google's end, it has to do with z-indexing getting messed up, whenever you use webkit, or so it seems.
There are two fixes for this, hopefully one of them works.
1. This is the preferred fix. Remove the webkit-transform from the DOM element that you load google maps into and set it's z-index to "auto". Also set it's child div to a z-index of "auto". You can do this with CSS like the following:
#googleMap{
-webkit-transform: none !important;
z-index: auto !important;
> div{
z-index: auto !important;
}
2. Remove the z-index value for every absolutely positioned element on your page that has one (apart from the Google Maps z-indexes), i.e. set z-index for all absolute positioned elements to z-index: auto.
I had experienced the exact same problem as described by the thread starter. In my case the whole navigation disappeared (navigation wrappers seems to be a popular div to mess with in this case, after some research). When I rid the Google Map div from the site the navigation showed up like it should.
Anyway, my solution was to add a direct style to my Google map div:
<div id="map" style="-webkit-transform: none; z-index: 10;"></div>
And that solved my case. Hope it might help someone out there!
Removing the translate globally broke other functionality in our app. It did however point us in the right direction.
This solution worked for us. We moved all the map pin elements back up to the 103 layer.
div[id*='marker_div_']{
-webkit-transform: translateZ(103px);
}
I experienced this same problem in Safari. In my safari it was causing my font on the affected div to become very thin and undefined. The cause I found was that the affected div was casting a shadow onto the div containing google maps. If I remove the drop show the issue is resolved.
i created a page on which i tried to attain the effect of bottom aligned tool bar like the one face book has. For that i made a div with highest z-index set the position to fixed and set the bottom 0 like
#bar
{
z-index : 11;
position : fixed;
bottom : 0;
height : 50;
left : 0;
right : 0;
}
it works fine but while scrolling it seems like the page takes time rendering, like the page is heavy, scrolling is smooth but the page rendering is just a little slow that produces a not so good scroll effect. Did anyone know whats up...
or did you even get me :p
Position:fixed in itself shouldn't be causing these problems.
It sounds like the browsers are just being slow in rendering your page. Is the page large or complicated? This could be caused by over complicated HTML, CSS and especially Javascript.
Try simplifying (or disabling, for JS) each one in turn.
(I'd look hard at any JS events or and CSS that uses the * selector.)
If that bottom bar is at the bottom of the HTML-code, it will be loaded (and rendered) after everything else. If the rest of the page is big (silly code, complex javascripts or giant images), this will probably make everything worse, as styles are applied more or less continously as the page loads.
Simple way to check this: Recreate the bottom-bar at a super simple page and see if you get the same effect. If so, your page is probably to big or complicated.
Or your computer is just plain slow :-)
If you've got a "background-attachment: fixed" rule that may also be causing similar problems. Another issue you have to be careful about is IE6 doesn't support position: fixed, so you have to do it with JavaScript - which also slows down the website.