I have a vertical scrolling website - It works fine in IE7 aside from a few margin issues and problems rendering some .PNGS - but I have one big problem;
I'm using two fixed positioned menus - one that slides out at an anchor point and one that just sticks to the bottom. Essentially - ones always at the top with the scroll and ones always at the bottom.
They stick, and work fine - problem is, I'm using z-index in the CSS and it seems IE7 is having some problems with it - with IE7 the sticky menus go behind the content. I read a suggestion trying to position it to 'relative'. But that would destroy the fixed.
Any suggestions? Thanks for anything -
Sub Question - of less importance, as I'm no longer carrying IE6 - but, is there a way to continue using these menus for IE6 - a way to work around it not reading position: fixed?
Here's an image to illustrate the problem better. http://tinypic.com/r/20fqqkp/7
Without any code it's tough to know for certain, but most likely the issue you are seeing is the z-index bug in IE.
Any element in IE6 or IE7 with position: relative set will generate a new stacking context. This means that the z-index of their elements not in the same stacking context won't necessarily stack as you'd expect.
For example, consider this HTML:
<div id="parent-1">
<div id="child-1"></div>
</div>
<div id="parent-2">
<div id="child-2"></div>
</div>
And this CSS:
/* Both parents create their own stacking context */
#parent-1, #parent-2 {
position: relative;
}
#child-1, #child-2 {
position: fixed;
}
/* Should be lower */
#child-1 {
z-index: 10;
}
/* Should be higher */
#child-2 {
z-index: 20;
}
According to the spec, #child-2 should always be stacked higher than #child-1 (and this is what you'll see in sane browsers). But since both parents have position: relative set, IE6-7 will have created 2 stacking contexts and might not do this for you.
The fix is to apply z-index to the elements creating the stacking contexts or to make sure all elements are in the same stacking context.
As for your IE6 problem, yes, you can emulate it with CSS expressions. Use the following in an IE6 only stylesheet:
/* Fixed to the top */
#top-fixed {
position: absolute;
top: expression(document.documentElement.scrollTop);
}
/* Fixed to the bottom */
#bottom-fixed {
position:absolute;
top:expression(
document.documentElement.scrollTop +
document.documentElement.clientHeight -
this.clientHeight
);
}
Try the zindex fix http://www.vancelucas.com/blog/fixing-ie7-z-index-issues-with-jquery/
Related
I am experiencing elements position misbehaviour into my page, in IE(11) only; live link here. The logotext, the menu and the left sidebar text, remain in place doesn't move with the wrapper when the left slider is open (clicking on info+ button). I've read about position: fixed + transition in IE problems.
I've tried to apply position: expression(fixed); to the header but something went wrong and the wrapper receive a brake-movement at open/closing slider. (The sidebar didn't work with position: expression(fixed);)
Also I've tried to tweak the css modifying the element position values in static/ absolute but without succees.Tests are made in full screen, the theme is not for mobile screens.Any thoughts?
LE: I've found a possible solution that works with the slider in IE11:
.header {
position: absolute;
}
.bar-side {
position: absolute;
}
Will work with the slider but also will move on vertical scroll.If I ca fix that somehow, could be a solution.
This may be way too late, but I had a similar issue with position:fixed and IE11, for a full page DIV (by specifying top: 0; bottom: 0; left: 0; right: 0;). Worked fine on Chrome, Edge, Firefox and Opera, but IE11 displayed the DIV at way under the full viewport size, and with rounded corners that seem to have inherited somehow from the parent.
Playing with the IE11 developer tools, I found an alternate option suggested as a parameter for position - "-ms-page". Using position: -ms-page sorted the issue; preceding this with position: fixed allowed the other browsers to carry on regardless.
Hope this helps others with a similar problem...
For a quick solution add transform separately for IE, in IE only css hack.
#media screen and (-ms-high-contrast: active), (-ms-high-contrast: none) {
.header, #bar-left{
left: 0;
transition: all .5s;
}
.shiftnav-open .header, .shiftnav-open #bar-left{
left:590px;
}
}
Move the header outside the .shiftnav-wrap and place it above it, and apply the translateX seperately for header movement.
.shiftnav-open header{
transform: translateX(590px);
}
It is not good idea to depend on its movement relative to the outer div.
elements with fixed positioning are fixed relative to the viewport/browser window rather than the containing element - http://www.w3.org/wiki/CSS_absolute_and_fixed_positioning
Another solution, you can use the header as absolute positioned, inside the left div #shiftnav-info.
ADD this script in your page. IE fixed position scroll issue fixed.
<script>
if(navigator.userAgent.match(/Trident\/7\./)) {
document.body.addEventListener("mousewheel", function() {
event.preventDefault();
var weelDelta = event.wheelDelta;
var currentOffset = window.pageYOffset;
window.scrollTo(0, currentOffset - weelDelta);
});
}
</script>
Isolated test case (view in IE 7 or IE 8/9 in IE 7 mode)
Viewing this page in IE 7 is causing my width value to be ignored. If you remove the padding value, the width is properly applied, but when you add in the padding, it causes the entire page to grow, and it treats the padding almost as margin. The larger the width of the page, the larger the blank area to the right of the element. I've been unable to find which bug this is, and, more importantly, how to fix it. Has anyone seen this and does anyone know a solution?
Things I've tried so far:
zoom fix
display: inline-block (recommended for double vertical padding issue)
It isn't line-height (it's a width issue...)
Screenshot of the issue:
This div should span the entire width of the page, and no more, but you'll notice the scrollbar here:
And the result of scrolling to the right:
This should not be there.
Examining the element in the browser tools shows the width to be incorrectly the full width of the page, instead of the full width minus the padding.
Disclaimer: I'll ignore the functional requirement and your comments on the other answers and just concentrate on the concrete problem.
This IE7 specific problem is caused by using an offset (e.g. top, right, bottom or left) on a relatively positioned element. If you offsets a relatively positioned element, then it will basically still retain the whole space of its original position. Note that this doesn't happen when offsetting absolutely positioned element.
Before the left offset is been applied, the relatively positioned element is due to its width and and the right padding completely out of the viewport and hence a horizontal scollbar will be generated. After the left offset is applied on the relatively positioned element, you're basically leaving a space of the same size as the offset on the other side of the offset, still outside the viewport.
A bit sane webbrowser will during redrawing however discover that there's nothing visible outside the viewport and hence hide the scrollbar again. IE7, however, isn't that smart enough and retains the scrollbar.
After all, using left offset was technically been the wrong solution. You should in first place have used margin-left instead of left. Unlike the offset, the margin doesn't leave an empty space on the original position, but really pushes the whole element to the desired position.
So, here's how your script is been fixed:
$('#el').css({
'width': document.body.scrollWidth - 200,
'padding-right': 200,
'margin-left': (-1 * (document.body.scrollWidth - 322) / 2) - 1
});
By the way, I wonder how that float: left; makes sense in this construct wherein you apparently want to simulate a 100% width. It'll probably be for other purposes not visible in the concrete example.
You can solve this without using javascript for calculating width, and no padding, instead use position: absolute. Here's an updated fiddle. It will work in any browser
#el {
background-color: #FFFF00;
min-height: 45px;
width: 100%;
position: absolute;
left:0;
right: 0;
top: 0;
}
http://jsfiddle.net/LRpHq/7/
I was having this problem with a skeleton.css implementation. Specifically, my #header was taking the width of body, which took the width of html. The remaining content had a set-width of 978px. So when the window was smaller than 978, the background of the header would only render to the width of the viewport. i.e. - if you started the render at 500 wide, that's all the wider #header would get. Dragging a wider width of the viewport had no problems, but right scroll cut the header to the size of initial viewport.
My fix: html,body { min-width:978px } /* your width may vary */
Since you seem to be fine with using Javascript, adjust your resize() function:
function resize () {
$('#el').css({'width':$(window).width(),'position':'absolute','left':'0px'});
}
Fixed the original post as it was off by miles.
edit:
Tested in a sandboxed IE7 and it works. (what can i say, i go out of my way to get something perfect, also am new around here so that bounty would really help to be very honest) to also note that it works natively in IE7, IE8 and IE9, FF3.6, Opera 10 and should work in Safari with no problem, Chrome didn't get mentioned as it's my default browser and it works, no doubt about it.
Here is the JS:
function resize () {
$('#el').trigger('resize').width('100%');
}
resize();
and the CSS:
#container {
width: 320px;
border: 1px solid #000000;
min-height: 500px;
margin: 0px auto;
}
#el {
background-color: #FFFF00;
min-height: 45px;
width: 100%;
position: absolute;
left: 0;
}
i found solution for similar problem here. see if it can helps you too.
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.
I'm working on a site that has a wrapper element, with a left and right sidebar, each floated within the wrapper. The left sidebar (which contains navigation) is clearing the right sidebar and pushing it to the bottom for some reason. I've tried fixing it in about 50 different ways. I originally thought changing the size and or margin would help. It didn't. I tried the 'display:inline' fix to no avail. I've tried a ton of other tweaks but I can not get it to work. You can view the site at www.ibgs2010.org and the css is www.ibgs2010.org/css/style.css (I'm trying to use a IE7 specific stylesheet to fix it). If anyone can help, I'd really appreciate it. I've burnt about 3 hours today just trying to fix this one little issue.
Looks like the problem is with the ajaxloader div - set its width to 697px (same as sidebar right) and that should fix your problem.
Try to remove the margins and paddings on your sidebar classes and have a inside wrapper with the margin and padding set to it. More failsafe this way so that margins don't increase the size of your div element. Browsers have a different way of rendering margins and paddings to elements.
Hope that helped you out.
Cheers
I think it's just that the floating content is being considered too wide to fit -- so, it's floating it down to where it will.
Instead of float, you might try position with left and right, respectively:
.content.wrapper {
position: relative; /* establish boundary for absolute positioning */
}
.sidebar.left {
position: absolute;
top: 0px;
left: 0px;
}
.sidebar.right {
position: absolute;
top: 0px;
right: 0px;
}
I propose you add the following:
#ajaxloader {
width: 737px;
float: left;
}
The width of 737px is derived from the 697px width plus the 40px left padding of of .sidebar.right
With this addition the IE7 and Firefox versions should look the same, give or take a pixel.
I include the yahoo reset css as the begining of every page (or css file). It really helps to level the playing field. Also with IE, always remember to specify width (even if it's 100%) and if your floating, make sure to display:inline.
I've isolated a little test case of IE7's z-index bug, but don't know how to fix it.
I have been playing with z-index all day long.
What is wrong with z-index in IE7?
Test CSS:
input {
border: 1px solid #000;
}
div {
border: 1px solid #00f;
}
ul {
border: 1px solid #f00;
background-color: #f00;
list-style-type: none;
margin: 0;
padding-left: 0;
z-index: 1000;
}
li {
color: #fff;
list-style-type: none;
padding-left: 0;
margin-left: 0;
}
span.envelope {
position: relative;
}
span.envelope ul {
position: absolute;
top: 20px;
left: 0;
width: 150px;
}
Test HTML:
<form>
<label>Input #1:</label>
<span id="envelope-1" class="envelope">
<input name="my-input-1" id="my-input-1" />
<ul>
<li>item</li>
<li>item</li>
<li>item</li>
<li>item</li>
</ul>
</span>
<br><br>
<label>Input #2:</label>
<span id="envelope-2" class="envelope">
<input name="my-input-2" id="my-input-2" />
</span>
</form>
Z-index is not an absolute measurement. It is possible for an element with z-index: 1000 to be behind an element with z-index: 1 - as long as the respective elements belong to different stacking contexts.
When you specify z-index, you're specifying it relative to other elements in the same stacking context, and although the CSS spec's paragraph on Z-index says a new stacking context is only created for positioned content with a z-index other than auto (meaning your entire document should be a single stacking context), you did construct a positioned span: unfortunately IE7 interprets positioned content without z-index this as a new stacking context.
In short, try adding this CSS:
#envelope-1 {position:relative; z-index:1;}
or redesign the document such that your spans don't have position:relative any longer:
<html>
<head>
<title>Z-Index IE7 Test</title>
<style type="text/css">
ul {
background-color: #f00;
z-index: 1000;
position: absolute;
width: 150px;
}
</style>
</head>
<body>
<div>
<label>Input #1:</label> <input><br>
<ul><li>item<li>item<li>item<li>item</ul>
</div>
<div>
<label>Input #2:</label> <input>
</div>
</body>
</html>
See http://www.brenelz.com/blog/2009/02/03/squish-the-internet-explorer-z-index-bug/ for a similar example of this bug. The reason giving a parent element (envelope-1 in your example) a higher z-index works is because then all children of envelope-1 (including the menu) will overlap all siblings of envelope-1 (specifically, envelope-2).
Although z-index lets you explicitly define how things overlap, even without z-index the layering order is well defined. Finally, IE6 has an additional bug that causes selectboxes and iframes to float on top of everything else.
http://www.vancelucas.com/blog/fixing-ie7-z-index-issues-with-jquery/
$(function() {
var zIndexNumber = 1000;
$('div').each(function() {
$(this).css('zIndex', zIndexNumber);
zIndexNumber -= 10;
});
});
In IE positioned elements generate a new stacking context, starting
with a z-index value of 0. Therefore z-index doesn’t work correctly.
Try give the parent element a higher z-index value (can be even higher than the child’s z-index value itself) to fix the bug.
I encountered this issue, but on a large project where HTML changes had to be requested and became a whole issue, so I was looking for a pure css solution.
By placing position:relative; z-index:-1 on my main body content my header drop down content suddenly displayed above the body content in ie7 (it was already displaying without issue in all other browsers and in ie8+)
The problem with that was then this disabled all hover and click actions on all content in the element with the z-index:-1 so i went to the parent element of the whole page and gave it a position:relative; z-index:1
Which fixed the issue and retained the correct layering functionality.
Feels a bit hacky, but worked as required.
I found that I had to place a special z-index designation on div in a ie7 specific styelsheet:
div { z-index:10; }
For the z-index of unrelated divs, such as a nav, to show above the slider. I could not simply add a z-index to the slider div itself.
If the previously mentioned higher z-indexing in parent nodes wont suit your needs, you can create alternative solution and target it to problematic browsers either by IE conditional comments or using the (more idealistic) feature detection provided by Modernizr.
Quick (and obviously working) test for Modernizr:
Modernizr.addTest('compliantzindex', function(){
var test = document.createElement('div'),
fake = false,
root = document.body || (function () {
fake = true;
return document.documentElement.appendChild(document.createElement('body'));
}());
root.appendChild(test);
test.style.position = 'relative';
var ret = (test.style.zIndex !== 0);
root.removeChild(test);
if (fake) {
document.documentElement.removeChild(root);
}
return ret;
});
It looks like not a ie bug, just for diffrent understanding to the css standard. If outside container is not specified the z-index, but the inner element specified a higher z-index. So the container's sibling maybe overlay the high z-index element. Even if like that, it only occurs in IE7, but IE6, IE8 and Firefox is ok.
In IE6 in general, certain UI-elements are implemented with native controls. These controls are rendered in a completely separate phase (window?) and always appear above any other controls, regardless of z-index. Select-boxes are another such problematic control.
The only way to work-around this issue is to construct content which IE renders as a seperate "window" - i.e. you can place a selectbox over a textbox, or, more usefully, an iframe.
In short, you'll need to put "on-hover" like things such as menu's in an iframe in order to let IE place these above built-in UI controls.
This should have been fixed in IE7 (see http://blogs.msdn.com/ie/archive/2006/01/17/514076.aspx) but perhaps you're running in some kind of compatibility mode?
This bug seems to be somewhat of a separate issue than the standard separate stacking context IE bug. I had a similar issue with multiple stacked inputs (essentially a table with an autocompleter in each row). The only solution I found was to give each cell a decreasing z-index value.
If you wanna create dropdown menu and having a problem with z-index, you can solve it by creating z-indexes of same value (z-index:999; for example).. Just put z-index in parent and child div's and that will solve problem. I solve the problem with that. If i put different z-indexes, sure, it will show my child div over my parent div, but, once i want to move my mouse from menu tab to the sub-menu div (dropdown list), it dissapear... then i put z-indexes of same value and solve the problem..
I solved it by using the developer tools for IE7 (its a toolbar) and adding a negative z-index to the container of the div that will be below that the other div.