Okay so while testing a site in various browsers everything worked flawlessly except for internet explorer 7. My problem is pretty weird one: my menu elements won't stand still. What I mean by that is that when I scroll the screen down my menu elements travel with me but only the link parts of them (all background stuff remains at the top) and when I scroll back up the menu elements are nowhere to be seen. Is this a known bug in IE7?
I have some suspicions that the problem might lie in position attribute in css as I use position:relative and left/right:50% to center my menu elements.
Found an answer myself. Here it is for those who someday struggle with the same thing.
The culprit was as suspected position. For some reason the relative positioned elements were treated as fixed or somehow seperated from the page layout so it "hovered" over everything while scrolling. To remedy this is one should set the position of the container/wrapper of the page to relative. So here it is in code:
#container{position: relative}
Huge thanks for all comments for prodding me in the right direction.
Related
I have a website that is exhibiting bizarre behavior that I don’t understand. I’m unable to tell if I’ve run into a bug or what I might be doing wrong.
The page has two elements, nav and main that each have overflow-y: scroll set. This is so they can be scrolled independently of one another. If I scroll the main element, and then hover over the pagination buttons at the bottom, the main element will jump back to the top (lose its scroll position). It also happens if I hover over the Octocat/GitHub symbol in the navigation on the right.
The common thread here is that the pagination buttons and the GitHub symbol on the right both have svg elements. If I get rid of the svg element the bug doesn’t happen. Also if I remove overflow-y: scroll from the main element the bug does not occur.
I’ve also noticed that the issue might be somehow related to having height: 100% set on the <html> tag. When it’s removed the issue no longer occurs, but unfortunately it can’t be removed otherwise the full width/height layout doesn’t work correctly.
Can anyone tell me why this is happening, if it’s a bug in Safari, and/or how to fix it? Thanks!
You can fix this by adding the following to body where your grid rules are defined. Sadly, I have no idea why this solves the issue.
body {
…
grid-auto-rows: 1fr;
}
After spending hours and hours on this, the only way I could figure out how to fix it was to switch from CSS grid to flexbox. 🤷🏼♂️
This is the diff that fixed it, if you’re curious.
This is a bug related to safari version 12.1, which is fixed in Safari Technological Preview.
https://bugs.webkit.org/show_bug.cgi?id=197189
However as a workaround in the mean time.
Can you try
overflow-x:hidden, overflow-y: scroll,
height between 50 to 95vh for the specific container depending on your surrounding elements. This is going to have minimal safari jump on hover and probably empty space at the bottom.
Even after Safari bug is fixed, seems that the bug still occurs on some other scenario. I successfully reproduced a similar behavior on Fluent UI dropdown: https://github.com/microsoft/fluentui/issues/23668
The workaround in my case was to change dropdown item height from "auto" to "100%".
I have a fixed horizontal menu that works well on firefox but it's presenting a problem in SOME instances of chrome. When the user scrolls down a white block covers the menu.
You can see the problem here: http://brandca.co/cterranum/
We've inspected the elements but it doesn't appear to be anything in the code and looks more like a rendering issue.
We've noticed that when we erase the element's overflow:hidden the problem fixes but we need this property to toggle the menu.
We haven't been able to pinpoint exactly when it happens since it looks it only happens in some computers and even then, a computer in wich the site rendered correctly had the problem happened oduring a presentation on the projection screen.
The fixed element was somehow screwing webkit's rendering, so I turn the element to position: absolute and on the scroll event I update the top value so it looks like its fixed. It's not pretty but it works.
Element has "position: absolute;" and inside it there is .inner-header which has "position: fixed;".
Try moving ".inner-header" outside of ".header".
I'm trying to create a parallax website. But then I have an issue with fixed positioning.
I have several sections , each with a background-attachment:fixed.
A position:fixed menu bar on the top with an hidden element in it on top of all sections.
A google map 100% with in one of the sections.
Now, the problem is when I scroll the page with animation in google chrome, the scrolling does not go smooth and it flashes several times while scrolling.
I do the scrolling with greensock scrollTo plugin , but that is not the problem as I also tested it with jquery .animate() method. Same result.
I did a research , and found out that chrome has a bug or problem with Fixed positioning ( and sometimes when you put hidden element in it )
Some pages suggested to use these two with the fixed elements :
-webkit-backface-visibility:hidden;
-webkit-transform: translateZ(0);
I added this to the fixed menu and some of the choppy behavior of it reduced , but still not smooth.
If I add this to the sections with background-attachment:fixed elements, the scrolling animation goes smooth but does not act as fixed anymore.
Somebodies says that chrome has problem with large images, some says it has issue with fixed position and somebodies had a solution that did not work for me :D
I uploaded the page :
http://www.FarzanMohajerani.com/test/parallax
just click anywhere on the page to scroll.
I also created a jsFiddle with the exact same code. But I don't know why it doesn't have the problem in jsFiddle :
http://jsfiddle.net/Farzanmc/cRqxT/5/
It would be great if anyone could direct me to the right solution or remind me if I'm doing anything wrong.
Thanks
This solved the issue for me:
-webkit-transform: translate3d(0,0,0);
Adding this rule turns the element into a layer in Chrome, which avoids repainting. In my unique situation the error was caused by browser re-painting.
I', having the same problem with Chrome at the moment and I narrowed down the cause to the following combination:
1) background: fixed;
2) transform: (any transform, even just putting scale(1), would instantly break it).
As long as an element that contains fixed background image doesn't have any "transform" on it, it works fine. But as soon as you even add "transform: scale(1);" which doesn't actually make any real transformation, it completely breaks the fixed background image. You can start scrolling, but it disappears. If it was outside of the screen, it will never appear at all, no matter how far you scroll.
So essentially, the problem is that Chrome at the moment can't handle fixed background images in transformed elements. No matter which level of descendent or ancestor we are talking about.
The thing is, this is pretty much an essential stuff that and I'm really hoping that it gets fixed as soon as possible, because it's extremely limiting. You can't disregard Chrome as if it's IE6.
And you can't apply "position: fixed;" on an "img" element, because it will be fixed to the first "transformed" ancestor, not to the real screen, since that's apparently how it's supposed to be treated, according to W3C. Although, some new value would be welcomed, some that can break all the way to the very window, and fixit to those coordinates.
I ran i to a same problem and fixed it this way:
I had to deal with fixed header on a website and anytime i would scroll with a mouse wheel the header would get choppy.... I had a display:none element in a header and as soon as i removed the element, header became fixed and steady, now it displays well no matter how fast i scroll.
on this site, http://dncminneapolis2012.com/new2 the content (where it says Minneapolis 2012 Democratic National Convention) is hidden beneath another div in IE7.
Can anyone tell me how to fix this?
Everything works great in Chrome, Firefox, and Safari
I don't have IE7 atm and this is just a tip not an answer, but there's a bug in which if you have an absolutely positioned element that has floated siblings, the AP element gets completely hidden.
I notice you have a ton of floats/AP'd elements so that may be the case.
Things to do when debugging:
remove all elements that aren't vital
use overflow:hidden to make sure elements arent being overly expanded and float drop occurs
apply zoom:1; all over the place through say, *{ zoom:1 } to trigger hasLayout.
I might take a look at this in the morning when I have IE7 available # work
Looks to be the <div class="main_content_wrapper">, as far as the IE developer toolbar can tell. The mysterious transluscent overlay randomly disppears as you click around in the DOM the toolbar displays, so not sure why it's there. Possibly something borking on the jquery fade-in routine?
Since they were in separate main divs (not nested under one main div), I had to rearrange my html to get the content to be in front of the container.
In FF and IE8 things look pretty good. I have a mock up of the drop down that I'm trying to create with rounded corners at bottom here: www.geowinedb.org/drop-down-test/test.html. In IE6 the mega div is extending to the far left edge of the window. What do I need to change/add (e.g. underscore hacks) to get the drop-down to shrink-wrap its contents (the ul).
p.s. I'll be back to ask about the z-index problem that blocks the drop-down (IE6 again), but if anyone want to answer that as well it will be much appreciated.
EDIT 20091107: More specifics on the requirements: It must work in IE6+ and the drop down menus cannot be fixed width. The client wants to be able to change menu item text at will and have the drop-downs size automatically.
EDIT 20091111: I never did find a great solution. The menu along with some other requirements for hover changes, meant that JavaScript was necessary. So, I found that I could position each main menu item absolute, then position each sub-menu div absolute (this solved the z-index problem), and lastly I computed the width from the underlying ul and set the outer div width. Then the rounded corners positioned themselves correctly on all the browsers that I needed.
Does it bother to use fixed width for your UL (and maybe UL.mega-b too) ? because this way you will definitely avoid this problem.
display:block in your UL can also be the cause of this.