I have a website at filmblurb.org.
The page-container of my site extends to the bottom of the window when you scroll out to make for a 100% CSS layout style, but for some reason even when the height is 100% for both the body and tag, those two elements go about halfway down the page and then stop when the viewport is zoomed out. When I'm profiling those elements in Google Inspect Element that is. My page-container is currently min-height: 100%, but that for some reason actually does extend to the bottom of the viewport when zoomed out.
I've also taken screenshots of what I'm seeing to give you a better idea. Here they are [link]i917.photobucket.com/albums/ad16/jtarr523/… (for the body) and
(for the HTML)...Both are not extending to the bottom.
Anybody know how to fix this?
I would appreciate it.
min-height: 100% on the html element means that that element will be at least as tall as the viewport. It does not mean that it will always extend to the bottom. If you scroll down, then you may still be able to scroll below the bottom of the <html> element.
The only way to prevent this (short of JavaScript) is to ensure that all elements on the page (that is, everything that could possibly cause a scrollbar) is kept within the html element. A simple way to force this is to put overflow: hidden on your html element:
body {
overflow: hidden;
}
If the problem is being caused by a float, then that will solve it. If the problem is caused by an absolute-positioned element or a negative bottom margin on the last element, then that will replace your problem with a more serious one: the page will be cut off at the bottom of the html element. You will then have to find the problem element some other way.
(The same applies to the body element; it will need its own overflow: hidden; to ensure that nothing can extend beyond it.)
Not sure exactly if it would work with browser zoom, but in my experience (and according to this question) you need to set the html tag height to 100% if you are setting container elements to min-height: 100%.
html { height: 100%; }
body { min-height: 100%; }
Replace body with a reference to your main container and it should still work. As far as I can tell there are no adverse reactions to setting html to 100%; it doesn't cut the page off or mess up any other styles.
Like I said, I'm not 100% sure this is related to your problem, but it's probably worth a shot.
Related
Not sure how to best ask my question. And I can't yet post screenshots. :( This issue does happen in mere current coding practices. You can currently even see this issue happening on Facebooks home page.
Here's my URL:
www.alpacanation.com
How to replicate live
Grab the right hand side of your browser and pull inwards. Eventually a scroll bar appears. Not necessarily bad. As I have a fixed with here. However… Notice the scrollbar is the length of the background color up in the top of my header which is actually creating a "Curtain" like effect.
Make matters worse:
If on other high level parent elements like .Footer or .Page you play around with overflow and position relative the curtain will then begin overlaying on top of the entire site.
Check out Facebook: They often have this issue as well. Obviously most don't notice it as it's not going over top of the content.
In either case I know there is something not right.
Help appreciated!
Add something like this to your CSS:
body { min-width: 980px; }
You have min-width: 980px; set in many of the elements on your page, but not on html, body, or .container. Once the viewport is smaller than this, these elements will overflow html and give you the scrollbars you're seeing.
But this doesn't make html any bigger. It--and its background--is still at the viewport size. This is why you get the "curtain" effect when you scroll.
Setting width: 100% on html doesn't fix this; this only sets html to 100% width of the browser window. If you're going to use min-width, make sure you you don't just apply it to elements that hold your content, but also those that have your backgrounds.
to fix this, add
html, body {
min-width: 980px
}
in your www.alpacanation.com/styles.css:40, then you are done. :)
EXPLANATION: the problem is this container,
<!— stat container —>
<div class=“container”>
<!— START FOOTER MENU SECTION —>
that container has width:980px which screws up the view because it forces that container to stay at 980px wide while the rest is shrinking, thus creates the ‘curtain’ like effect.
I have done some testing and from what I can see there is a bug in mobile Safari on ios6.
When adding overflow:hidden on the body tag and moving an element out of the body using transform:translateX(100%); It creates an extra scrollable space for that element.
On all desktop browsers it is "hidden".
Here is a demo: http://jsfiddle.net/mUB5d/1 . Open that in Mobile safari and you will see what is wrong.
Could anyone take a look at safari 6 on Mac OS to see if the bug is present there too?
Does anybody know of any workaround besides creating another parent around my element?
Thanks for your feedback!
Nope. Safari 6 on Mac does not present with the bug. Scrollbars are not present.
I ran it on OSX Mountain Lion (10.8.2)
To further answer your question, the reason this is happening probably has more to do with Mobile Safari's zoom rendering than an overflow hidden bug. The element is in fact being hidden off screen (notice below where I have scrolled over to the right all the way, it still doesn't show me the full 100% width element - 90% of it is in fact being hidden.
It likely has something to do with iframes, and page zoom. Still looks like a bug though.
I'm assuming you're demonstrating in JSFiddle from a real life example. If you go back to your real life example (apart from iframe territory), try adding this meta tag to the head if you don't already have it, and see it this helps:
<meta name="viewport" content="width=device-width, initial-scale=1">
This is normal behaviour on iOS (and iOS only). You can work around it by declaring overflow: hidden on both html and body element. In addition, you should set the body to position: relative.
Overflow behaviour
There are several things at play here. To understand why the fix works, we first need to have a look at how the overflow of the viewport is set.
The overflow of the viewport is determined by the overflow setting of the html element.
But as long as you leave the overflow of the html element at its default (visible), the overflow setting of the body gets applied to the viewport, too. Ie, you can set either html or body to overflow: hidden when you target the viewport. The overflow behaviour of the body element itself is unaffected - so far.
Now, if you set the overflow of the htmlelement to anything other than visible, the transfer from body to viewport does no longer happen. In your particular case, if you set both overflows to hidden, the setting of the html element gets applied to the viewport, and the body element hides its overflow as well.
That's actually the case in every reasonably modern browser out there, and not specific to iOS.
iOS quirks
Now, iOS ignores overflow: hidden on the viewport. The browser reserves the right to show the content as a whole, no matter what you declare in the CSS. This is intentional and not a bug, and continues to be the case in iOS 7 and 8. There is nothing anyone can do about it, either - it can't be turned off.
But you can work around it by making the body element itself, not the viewport, hide its overflow. To make it happen, you must first set the overflow of the html element to anything other than visible, e.g. to auto or hidden (in iOS, there is no difference between the two). That way, the body overflow setting doesn't get transferred to the viewport and actually sticks to the body element when you set it to overflow: hidden.
With that in place, most content is hidden. But there still is an exception: elements which are positioned absolutely. Their ultimate offset parent is the viewport, not the body. If they are positioned somewhere off screen, to the right or to the bottom, you can still scroll to them. To guard against that, you can simply set the body element to position: relative, which makes it the offset parent of positioned content and prevents those elements from breaking out of the body box.
Answering in code
There is one final gotcha to watch out for: the body itself must not be larger than the viewport.
So the body needs to be set to 100% of the viewport width and height. (The credit for a CSS-only way to achieve it goes to this SO answer.) Margins on the html and body elements have to be 0, and the html must not have padding or a border, either.
Finally, in order to deal with body padding, and in case you ever want to set a border on the body, make the math work with box-sizing: border-box for the body.
So here goes.
html {
overflow: hidden;
height: 100%;
margin: 0;
padding: 0;
border: none;
}
body {
overflow: hidden;
position: relative;
box-sizing: border-box;
margin: 0;
height: 100%;
}
NB You can set body padding and border as you please.
After struggling with this for a while I've found that both html and body tags need overflow hidden to actually hide the overflowing contents. On elements inside body overflow hidden works fine, so our choice is an extra css rule or a wrapper element.
for me it works
I have implemented in the left side menu
if($('.left-menu-panel').is(':visible')) {$("body").addClass('left-menu-open');$("html").css('overflow-y','hidden'); $('body').click(function() {$("body").removeClass("left-menu-open") ;$("html").css('overflow-y','visible'); });$('#off-canvas-left').click(function(event){event.stopPropagation();}); }
A page I'm working on has a div that spans its width. Its height has to resize according to the browser window. Here's how I've got it so far:
#vid_window{
position:absolute;
float:left;
background-color:#000;
width:100%;
height:57%;
margin-left:auto;
margin-right:auto;
overflow:hidden;
}
At the bottom of the page is a 'menu' to play an assortment of videos in the above div, and the video, of course, will have to resize with the height of the div. The div is absolutely positioned, per the client. That's not a problem:
#vid{width:100%;height:100%:}
As it will fill #vid_window
Here's the problem: When the browser page resizes, it doesn't take long for the 'menu' to begin overlapping the vid window. I know I can reduce the percentage, but, I may not, per the client. They want the lion's share of the page to be able to display the video, but they, of course, don't want the menu to overlap the window or the vid.
Here's the question: Is there a way to have the vid_window and vid resize exponentially according to the browser window, such that if the window is fully expanded, the vid_window is at 57%, but if it's half-size, the vid_window would be, say, 30%?
Here's a link to the page, if you'd like:
page
From what you've described, it sounds like you'd be better off absolutely positioning the menu at the bottom, and using relative postioning on vid_window. With a little JavaScript you can resize it correctly, and it should resolve your overlap issue. If you're allowed to use it, you can make quick work of it with jQuery.
Like James says the best way I can think of for you to do this is set a class on the Div vid_window set the height % in the class and check the display window size to determine your optimal settings. Also I would probably set a min-height so that the page won't go below that height and for backwards compatibility look at Modernizr. http://www.modernizr.com/
------EDIT------
That the Header and footer will never be off of the page. One way to reduce the problems you are having is setting the height on the header and footer to percentages so that they will scale with the height of the body
html,body { height:99%; min-height: 100%; }
header { height:22%; min-height: 100px; }
#content { height: 56%; min-height: 200px; }
footer { height:21%; min-height: 100px; }
The min-height values can be whatever you think is appropriate for the smallest height you want to go. The percentage heights on the rest should auto scale you header footer and consequently your content. This will however force the footer to go off the page at a certain point (when all min widths are met and the browser window continues to shrink). I do think that this would be desirable and should meet your clients needs. If not then you are going to get into a very complicated javascript that is not always going to do the math just right because of how each browser handles padding and height calculations. On top of that if they disable javascript then it would never work.
I want my floating sidebar to stop before it hits the footer - the only solutions I have found so far involve using javascript, but I'd prefer if there were a way to go without if possible!
a baisc example: jsfiddle example
By adding the code below, I can get it to stop, but it then pushes everything inside my sidebar way up the page:
bottom: 500px;
This is not exactly what you are looking for, because I can't think of any solutions that don't involve any JS
What you can do though - if you give the footer element a position (relative or absolute), the sidebar will slide down behind as the page scrolls.
.footer
{
width: 100%;
border: 1px solid green;
height: 500px;
background-color: green;
position:relative;
}
Ok, your problem is, you don't really understand HTML container bounding, and flow.
I would spend some time looking at HTML Flow tutorials, and understanding exactly whats happening, as it will make your life in the future much easier.
Another trick is to put borders around every containing structure such as DIV's, so that you can see how each of your objects are nested, etc...
The problem is, when you take and add bottom:500px;, you are absolutely positioning the footer, this automatically removes it from the normal HTML flow. I am guessing your right toolbar is out of flow as well.
So instead of using absolute positioning on either the footer or the right side toolbar, you will need to use a bounding outer container that encapsulates the whole page, then place each element on the page in the order you want the flow, using float:left, float:right to get your vertical positioning. As long as your footer is the last thing within your bounding container, and all elements are within the flow, and the width on the footer is set to 100%, you should get the behavior your looking for.
In my page there's only one image. Kind of 1500x3000 px.
In the printer, I need that this image's maximum width to be the width of the page, so I did: width 100% in the css, and it works.
But the height... the old bullshit of height 100% will never work. Because it always will be 100% of the parent container, then someone must have height defined. Or html or body.
So, my question is: make this image fit in one page.
Any ideas?
One way to do it would be to perform some calculations to find out what width would cause the length to be exactly one page, and then set your width in the CSS accordingly.
If I understand this right, could you do
.OnePageImage { height: 100%; width: 600px; }
Where 600px (the width) is the total width of the page. Then the image would fit on one page (albeit with some distortion potentially). You could also add a css page break style to a div before and after the image, which is done like this:
.break { page-break-after:always; }
Then the code would look like this:
<div class="break"></div>
<img src="[your image src]" class="OnePageImage" />
<div class="break"></div>
The only thing that limited the print output to a single page for me was setting the height in cm of a container element that wrapped the entire page, and also setting it's overflow to hidden. For some reason this didn't seem to work on the body element.
body > section {
padding:0 !important;
margin:0 !important;
height:25.7cm !important;
overflow:hidden !important;
}
Incidentally, I had hoped that setting page-break-inside to avoid on the body or the container element might have been the solution to limiting to a single print page but that doesn't seem to have any effect at all.
Ok sorry for putting the "solution" as a comment:
What I've ended up doing was assume that 99% of the clients (that's true) they use a single page size. So I put some warning in the print interface that will only work with the page size "X". too bad. but it's working out so far