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>
Related
So this morning I got an automatic update to IE 11, after checking my eyes it appears that some of my background images are blurry.
I had to check that it was not my image causing the problem, so after firing up Chrome, they were nice and crisp again...
I am completely baffled.
I've now uninstalled the IE11 update and they are once again nice and crisp in IE10... Has anyone else encountered this?
I've included a screen shot showing the images in the different browsers.
Here is a link to a jsfiddle, I don't have IE11 any longer to test but its the same markup and CSS that I am using: http://jsfiddle.net/3g52E/
Well i can see what is causing this problem. It's the border-radius of your ._ui.
Now i can't tell you why this happens. However if you want to fix this you can or don't use border-radius or, which is a better solution i my opinion, use the <img> tag to generate the background.
Use image element
<img src="http://i.imgur.com/DauuVHW.png" />
Now to cut-off your image you can just use position: relative;, position: absolute; and a overflow: hidden;:
.block1 > div
{
position: relative;
overflow: hidden;
}
This will add the properties on ._ui _bre and ._ui _com.
Where the basic image properties are:
img
{
position: absolute;
left: 2px;
}
Now you can just use the top and bottom offset for the the image positioning. Where as you used background-position before:
._bre._ui img
{
top: -68px;
}
._com._ui img
{
top: -24px;
}
This way your image is not a part of the element which has border-radius anymore, which caused this problem. They have a more clear seperation now; 2 different elements.
jsFiddle
There is probably more elegant way to fix blurry images in IE 11.
In our app we have icons on buttons with round corners. Removing round corners or using <img> for icons were not options.
However, what worked for us was "classic" images optimization for retina displays, i.e. saving button background images with twice larger resolution and then specifying original size in background-size.
Looks great in IE 11 and on retina displays.
According to this:How to write a CSS hack for IE 11?
I added this code to my CSS:
#media all and (-ms-high-contrast:none){
*::-ms-backdrop, .my_elements_with_border_radius { border-radius: 0 }
}
With this browser hack the borders are not round anymore in IE11 but at least the background images are not blurry anymore. In any other browsers they are still round.
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'm trying to position a check-mark next to a menu item by doing the following:
#userInfo div.dropDownContent p span
{
position: absolute;
margin-left: -20px;
}
A span inside a paragraph is absolutely positioned in order to preserve the centering of the menu item's text, otherwise the check-mark is centered along with the text and it makes it look bad.
As you can see in this jsFiddle, the check-mark looks ok in your average Windows browser, but Safari on Mac and iPad (perhaps even Chrome on Mac) shows the check-mark outside the menu, and there's nothing I can do to make it move even a pixel.
Does anyone know what I'm doing wrong? Is it a webkit bug? Thanks.
I do see that odd behavior in Safari, and I really can't explain why it's in that browser only.
That being said, this updated fiddle should show you what worked for me.
Basically, instead of positioning the span absolutely, I used relative positioning and set it to left -20px like so:
#userInfo div.dropDownContent p span
{
position: relative;
left: -20px;
}
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/
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.