Let's say we have 2 <div> elements, one being the parent, other being the child.
Is there a way to make only the parent <div> scrollable on Chrome and only the child <div> scrollable on FireFox?
This might sound a bit weird, but this is something I really need to implement on my project, because FireFox is acting really weird on that matter.
Thanks in advance.
UPDATE:
Here's a simplified description of the project I mentioned.
I'm intending to design a personal HTML template with page transitions. So each page will be displayed/hidden with a transition effect when user clicks on a menu item.
I'm using a very simple transition effect I wrote myself. So, <div id="main"> is the parent and some <div class="inner-page"> are the children. Needless to say that, based on their content, each .inner-page has different height.
For #main I've set overflow-y: scroll;. On Chrome it works flawless. So, with every .inner-page being displayed, the length of the scrollbar is updated based on the height of the active page.
On FireFox however, it's a different story. The length of scrollbar doesn't change and is always the same,
based on the length of the page which has the most and longest content. So when other pages (which have fewer content) are active, there's always a huge empty scrollable area at the bottom of that active page.
An alternative solution I tried (which worked) was to set overflow-y: scroll; for .inner-page instead of #main to solve the scrollbar length issue. But then I had to hide the scrollbar, because with each page transition, the scrollbar comes and goes with the page as well, something that doesn't look good at all.
Follow this CodePen link to see a simplified version of my code and how the scrollbar behaves differently on Chrome and FireFox.
Check the browser on page load, Here and add set the overflow of div hidden for Firefox.
overflow: hidden;
Lets say you added class ".firefox-scroll"
.firefox-scroll { overflow: hidden; }
Related
weird bug here. Searched on the internet for hours but no working solutions yet :(
https://www.*****.*****/
It only happens on the page with parallax, a page without parallax is fine (biografie page).
What happens is that when you look closely, you will see that the white transparant-ish header flows OVER your scrollbar.
When taking a closer look you will see that the whole body is floating over my scrollbar.
Does anyone know a way to 100% fix this? I tried lots and lots of answers on the internet but none gave me a working solution.
Hope someone can explain to me what is happening and how to solve it.
Best regards
You can't place the menu below the scrollbar, because the scrollbar on pages with .parallax containers is not the <body>'s scrollbar, but .parallax's scrollbar.
And you can't place element A between element B and element B's scrollbar, unless element A is a descendant of element B.
However, the real problem is not placing the menu under the scrollbar. The real problem is being able to use the scrollbar (click its top arrow) through the menu, where they overlap.
Which is quite possible, using:
.menu {
pointer-events: none;
}
.menu-wrapper > * {
pointer-events: all;
}
(This makes the menu transparent to pointer events, except for children of .menu-wrapper, which do not overlap the scrollbar).
I'm trying to build my interface using Material-UI (current version is 3.1.2.)
A while ago when I was using Bootstrap4, I added style="overflow-y: scroll; height: 100%" to my head tag to always show a scrollbar to stop the app from jumping around when the page content grew longer than the screen.
Now that I'm trying to use Material-UI, the overflow setting seems to cause problems when combined with Material-UI's popup components (popper, menu, etc.)
I read in the FAQ that this is a known issue with a workaround: https://material-ui.com/getting-started/faq/#why-do-the-fixed-positioned-elements-move-when-a-modal-is-opened-
But I'm not sure what that's telling me to do.
What is implied by the phrase "apply a global class" in the following?
"apply a global .mui-fixed class name ... to handle those elements."
Where do they intend that mui-fixed would be added - to every component in my app? To the anchor of the menu/popper? Or do they mean that I'm supposed to apply it "globally" (ie. high up in the React page component hierarchy somehwere?)
In the meantime, as a workaround, I've just removed the overflow styling from my html element.
The app content still jumps about when the content grows/shrinks across page size, but it seems less ugly than when I was using Bootstrap.
I tried adding the mui-fixed class to my body, so when the app starts, it looks like:
<body style="overflow-y: scroll; height: 100%" class="mui-fixed">
So when the page is short, there is a disabled scrollbar. If the page grows, the scrollbar becomes enabled.
Then, while the menu popup is displayed, Material-UI changes it to this:
<body style="overflow: hidden; height: 100%; padding-right: 17px;" class="mui-fixed">
Which looks fine, regardless of the content's length. But then when the menu is dismissed, Material-UI changes the body element to:
<body style="height: 100%; padding-right: 0px;" class="mui-fixed">
The overflow style is gone and this results in the scrollbar being removed entirely if the page content is shorter than the window - so the page content "jumps" across to fill the space from the missing scrollbar.
This is for scrollbar if I got it correct, then it would be apply "globally" one time.
in your styles.ts you can add:
'#global': {
'.mui-fixed': {
// something here
},
},
and it will apply globally!
I have used Accordion and Slideshow on my site.
http://www.delightbranding.com/
when you click Play. For some reason the scroll bar appears shifting the page.
Guess i am missing setting height for some div. Please help.
This one seems to be the bad apple:
<div class="control-next">
When the "Play" item is selected, this div expands below the HTML content, causing your page to grow.
Remove the height from .control-next css class
.control-next {
position:absolute;
right:0;
top:201px;
bottom:201px;
/*height:432px;*/
}
this is only happening for me in IE9 (I'd wager all versions of IE) and only when my browser window is short.
I tend to add a CSS rule to my html tag of
overflow-y: scroll;
Which places the scrollbar on the page always so that longer content doesn't make the browser behave inconsistently.
Not sure if this will help you in this case, but worth a try.
I'm having a problem with a dropdown menu under IE (6 and 7).
http://www.amaconsulting.pl/promocje.html
As you can see, the dropdown hides behind the main content area in IE.
It's a known bug and general advice is to set a z-index for header and content areas, so IE knows their "place", explained in the article here: http://bit.ly/coSPcI
I've set the z-index of .header div to 20 and .featured, .content, .primary, .main to 1, trying to find the right div to fix the problem. While the dropdown stopped hiding behind the .featured div, it still hides behind the main content divs (either .primary or .main, .secondary is fine).
The z-indexes for these divs are set in a separate stylesheet, ie.css, in case someone'll be looking for them.
If someone could provide some advice, I'd be very grateful.
Ok originale solution here - Swiss credit website. This works but uses a complicated z-index solution.
Here is very simple and improved solution here - Jeyjoo stock image gallery
This works in IE6+, firefox, opera, safari and chrome
Solution
The HTML
<div id="container_page" class="container_page">
<div id="container_header" class="container_header">
NAV BAR GOES HERE
</div>
<div id="container_body" class="container_body">
...body text...
</div>
</div>
The CSS
#container_page #container_header {position:relative;z-index:2;}
#container_page #container_body {position:relative;}
why it works
You have to tell IE how the two divs relate to one another.
In IE if an absolutely positioned element has a z-index then it’s containing relatively positioned element must specify a z-index (z-index:1) in order for the absolutely positioned element to be able to appear on top of other relatively positioned elements.
So I think that you need to give your ul.nav a z-index of 1. I actually wrote about this on my blog.
Updated:
So if I change the visibility style of the hidden ul to visible it appears above the div as it should as long as ul.nav has a positive z-index value. Therefore, I think that this has something to do with the way your JS renders the dropdown menu from that hidden UL. Unless I have all your HTML/CSS/JS I can't really solve this so I can only point you in the right direction and I think that understanding this page will help you a lot.
I managed a z-index work around here on a submenu - Chkredit - swiss credit website
Works in all versions of IE and is light and 100% CSS (no javascript).
IE does not use z-index correctly.
Check the z-index's in the CSS code of the website. You will need to put a z-index -1 on the items your menu is hiding behind.
I working on exactly the same problem for my own image gallery right now (go to "top image" page) - jeyjoo image gallery. When I sort this one out, I will post the full solution here.
Compare these 3 URLs (look at the top navigation bar in each case):
http://fast.kirkdesigns.co.uk/blog
as above but with the url fragment #navigation
as above but with the url fragment #node-2655
Note, that the only difference is the URL fragment on the end.
The first two pages display absolutely fine (in Firefox at least). It's the third one where the problem lies. The fragment #node-2655 pushes the top navbar off the top of the screen. When you then scroll back up to the top of the page, the navbar has been cut in half. This happens when using any URL fragment that causes the navbar to be out of the initial viewport when the page is first loaded.
So, how can using a url fragment affect the css layout like this?!
THE SOLUTION:
as suggested below, removing the overflow: hidden on the container element that held the navbar fixed the problem. I'd love to understand why though!
Remove the overflow:hidden on #main in css_75afd7072eaf4096aaebf60674218e31.css
I'd say it's a rendering bug in FireFox as it's fine in Opera. There shouldn't be anyway an anchor would change the CSS like you say (unless you are using jQuery or something).
I am having this problem too, and think I can see what is happening.
The "column" block with the massive (5678 pixel) margin and padding makes that block very tall. In browsers other than Firefox, the positive and negative values cancel each other out, but FF really does make it that tall - kind of.
FF also knows the two cancel each other out, but seems to look at the 5678px padding and decides the column block is poking out the bottom of the #wrapper block. This is overflow - and with overflow set to auto on #wrapper, you see the true size of #wrapper with a scroll-bar down the side.
With overflow set to hidden, FF takes away the scrollbar, but still seems to scroll the contents of #wrapper so that the item the fragment points to is at the top of the page. This is normal behaviour for fragment links in scrollable blocks, but since there is no scrollbar, you cannot scroll the content back down again, hence it looks like the layout has been effected by the fragment.
So in short, I suspect that FF is operating an invisible scrollbar in this example. That could be considered a bug, but it is probably correct behaviour. Being able to scroll the content up and down inside a non-overflowed fixed-sized block using URL fragments, is a technique that can be used effectively to implement image "sliders" that work even in the absence of JavaScript.
Hope that helps. This has been puzzling me for years, and this explanation suddenly struck me out the blue. My current workaround for this is to use jQuery "scroll to" plugin to scroll the whole page down to the fragment, as this seems to prevent the contents of #wrapper from scrolling internally.
You can also take "display: hidden" off #wrapper, but your page then ends up half a mile long.
I'll just point out that there may be some weird inheritance from the 30+ stylesheets linked to in the head. There may not, either, and it's probably a rendering bug (possibly related to :target styling) that Dan suggested. I just felt it worth pointing out that if you've got more than thirty stylesheets, you likely to start seeing some weirdness, whatever else might happens.
The reason is the column with the large padding has expanded it's container, but the expansion is then hidden but overflow:hidden; but with the use of the fragment it is being scrolled into the position of the fragment, effectively chopping off anything above that. You can use javascript and set scrollTop to 0 and it scroll it back to the normal position.
Basically a wierd edge case which browsers do not seem to handle very well.
Sorry this isn't an "answer," tho it is a response to the other comments here. This problem is just flabbergasting. It is very easy to isolate (i.e., has nothing to do with number of stylesheets), and doesn't have a proper "solution," as there is no way to achieve the desired rendering.
<!DOCTYPE html>
<html>
<head>
<style>
#container {
margin: 1em auto;
width: 40em;
}
#wrapper {
overflow: hidden;
position: relative;
}
#c1 {background-color: #aaf;}
#c2 {background-color: #ccf;}
.column {
float: left;
margin-bottom: -5678px;
padding-bottom: 5678px;
width: 50%;
}
#footer {
background-color: #eee;
padding: 1px;
text-align: center;
}
p {margin: 1em;}
</style>
</head>
<body>
<div id="container">
<div id="wrapper">
<div id="c1" class="column">
<p>This is some content in a short column. We would need some Javascript to change its height if we wanted a different background color for each column to stretch the full height of the respective columns...or we can use large padding together with an equal negative margin.</p>
<ul>
<li>Jump to P1</li>
<li>Jump to P2</li>
<li>Jump to P3</li>
</ul>
</div>
<div id="c2" class="column">
<p id="p1">The desired effect is to have the height of the two columns appear the same. We use 'overflow:hidden' on the containing div (#wrapper) to wrap it around the floated columns.</p>
<p id="p2">These paragraphs have fragment identifiers. Problem comes in when clicking one of the links on the left. Instead of scrolling just the page, the browser scrolls the div with 'overflow:hidden' so the target is at the top. It does this even if the target is already visible.</p>
<p id="p3">Opera does not exhibit this behavior. This occurs in Chrome/Safari, Firefox, and IE. (Interestingly, IE also works as expected if we completely remove the DOCTYPE declaration.)</p>
</div>
</div>
<div id="footer">
<p>Footer stuff.</p>
<p>To see why 'overflow: hidden' (or any other piece of the CSS) is needed, just try disabling it.</p>
</div>
</div>
</body>
</html>
Just as a side-note, the above technique is generally used to provide flexible-width mulit-column layouts. This is probably becoming less important these days as fixed-width layouts are becoming a lot more comment - browsers are able to magnify the web page to see small text, and fixed-width makes it a lot easier to control the typography of a page, e.g. set the width (in ems) to display the ideal nine words per line regardless of what font size and magnification the user chooses.
Sorry if that does not sound like an answer, but it is basically suggesting to discard this old model and consider moving to fixed-width columns (which is a whole new subject).
I was able to solve this with some javascript to scroll the body to the position the overflow hidden element was scrolled to.
setTimeout(() => {
let intendedScroll = document.getElementById("fragmentfix").scrollTop;
document.getElementById("fragmentfix").scrollTop = 0;
window.scrollTo(0, intendedScroll);
}, 0)