I have a very odd issue... in every browser and mobile version I encountered this behavior:
all the browsers have a top menu when you load the page (showing the address bar for example) which slide up when you start scrolling the page.
100vh sometimes is calculated only on the visible part of a viewport, so when the browser bar slide up 100vh increases (in terms of pixels)
all layout re-paint and re-adjust since the dimensions have changed
a bad jumpy effect for user experience
How can avoid this problem? When I first heard of viewport-height I was excited and I thought I could use it for fixed height blocks instead of using javascript, but now I think the only way to do that is in fact javascript with some resize event...
you can see the problem at: sample site
Can anyone help me with / suggest a CSS solution?
simple test code:
/* maybe i can track the issue whe it occours... */
$(function(){
var resized = -1;
$(window).resize(function(){
$('#currenth').val( $('.vhbox').eq(1).height() );
if (++resized) $('#currenth').css('background:#00c');
})
.resize();
})
*{ margin:0; padding:0; }
/*
this is the box which should keep constant the height...
min-height to allow content to be taller than viewport if too much text
*/
.vhbox{
min-height:100vh;
position:relative;
}
.vhbox .t{
display:table;
position:relative;
width:100%;
height:100vh;
}
.vhbox .c{
height:100%;
display:table-cell;
vertical-align:middle;
text-align:center;
}
<div class="vhbox" style="background-color:#c00">
<div class="t"><div class="c">
this div height should be 100% of viewport and keep this height when scrolling page
<br>
<!-- this input highlight if resize event is fired -->
<input type="text" id="currenth">
</div></div>
</div>
<div class="vhbox" style="background-color:#0c0">
<div class="t"><div class="c">
this div height should be 100% of viewport and keep this height when scrolling page
</div></div>
</div>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
Unfortunately this is intentional…
This is a well know issue (at least in safari mobile), which is intentional, as it prevents other problems. Benjamin Poulain replied to a webkit bug:
This is completely intentional. It took quite a bit of work on our part to achieve this effect. :)
The base problem is this: the visible area changes dynamically as you scroll. If we update the CSS viewport height accordingly, we need to update the layout during the scroll. Not only that looks like shit, but doing that at 60 FPS is practically impossible in most pages (60 FPS is the baseline framerate on iOS).
It is hard to show you the “looks like shit” part, but imagine as you scroll, the contents moves and what you want on screen is continuously shifting.
Dynamically updating the height was not working, we had a few choices: drop viewport units on iOS, match the document size like before iOS 8, use the small view size, use the large view size.
From the data we had, using the larger view size was the best compromise. Most website using viewport units were looking great most of the time.
Nicolas Hoizey has researched this quite a bit: https://nicolas-hoizey.com/2015/02/viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers.html
No fix planned
At this point, there is not much you can do except refrain from using viewport height on mobile devices. Chrome changed to this as well in 2016:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/BK0oHURgmJ4
https://developers.google.com/web/updates/2016/12/url-bar-resizing
You can try min-height: -webkit-fill-available; in your css instead of 100vh. It should be solved
in my app I do it like so (typescript and nested postcss, so change the code accordingly):
const appHeight = () => {
const doc = document.documentElement
doc.style.setProperty('--app-height', `${window.innerHeight}px`)
}
window.addEventListener('resize', appHeight)
appHeight()
in your css:
:root {
--app-height: 100%;
}
html,
body {
padding: 0;
margin: 0;
overflow: hidden;
width: 100vw;
height: 100vh;
#media not all and (hover:hover) {
height: var(--app-height);
}
}
it works at least on chrome mobile and ipad. What doesn't work is when you add your app to homescreen on iOS and change the orientation a few times - somehow the zoom levels mess with the innerHeight value, I might post an update if I find a solution to it.
Demo
Look at this answer: https://css-tricks.com/the-trick-to-viewport-units-on-mobile/
// First we get the viewport height and we multiple it by 1% to get a value for a vh unit
let vh = window.innerHeight * 0.01;
// Then we set the value in the --vh custom property to the root of the document
document.documentElement.style.setProperty('--vh', `${vh}px`);
// We listen to the resize event
window.addEventListener('resize', () => {
// We execute the same script as before
let vh = window.innerHeight * 0.01;
document.documentElement.style.setProperty('--vh', `${vh}px`);
});
body {
background-color: #333;
}
.module {
height: 100vh; /* Use vh as a fallback for browsers that do not support Custom Properties */
height: calc(var(--vh, 1vh) * 100);
margin: 0 auto;
max-width: 30%;
}
.module__item {
align-items: center;
display: flex;
height: 20%;
justify-content: center;
}
.module__item:nth-child(odd) {
background-color: #fff;
color: #F73859;
}
.module__item:nth-child(even) {
background-color: #F73859;
color: #F1D08A;
}
<div class="module">
<div class="module__item">20%</div>
<div class="module__item">40%</div>
<div class="module__item">60%</div>
<div class="module__item">80%</div>
<div class="module__item">100%</div>
</div>
For me such trick made a job:
height: calc(100vh - calc(100vh - 100%))
We have new viewport units lvh, svh and dvh to the rescue. This was demonstrated in the latest Google I/O 2022 video on web works.
You would probably want to stick with dvh for the browser to adapt to the mobile device's hidden tabs while scrolling. It works the similar way for width with dvw, lvw and svw units.
Here is a neat illustration from the video: https://youtu.be/Xy9ZXRRgpLk?t=982
Can I use?
This was currently working on my Chrome canary with the flag "Experimental features" enabled.
You can do this by adding following script and style
function appHeight() {
const doc = document.documentElement
doc.style.setProperty('--vh', (window.innerHeight*.01) + 'px');
}
window.addEventListener('resize', appHeight);
appHeight();
Style
.module {
height: 100vh; /* Fallback for browsers that do not support Custom Properties */
height: calc(var(--vh, 1vh) * 100);
}
Set your body position to fixed, set the height to 100%
body { position: fixed; height: 100% }
That's it, then the mobile browser will understand what you want.
Now the body will grow or shrink following the browser's view height, no matter if there is a URL bar or not, or if there are tabs (like in mobile safari) or not. The body will always get full view.
For many of the sites I build the client will ask for a 100vh banner and just as you have found, it results in a bad "jumpy" experience on mobile when you begin to scroll. This is how I solve the problem for a smooth consistent experience across all devices:
I first set my banner element CSS to height:100vh
Then I use jQuery to get the height in pixels of my banner element and apply an inline style using this height.
var viewportHeight = $('.banner').outerHeight();
$('.banner').css({ height: viewportHeight });
Doing this solves the issue on mobile devices as when the page loads, the banner element is set to 100vh using CSS and then jQuery overrides this by putting inline CSS on my banner element which stops it from resizing when a user begins to scroll.
However, on desktop if a user resizes their browser window my banner element won't resize because it now has a fixed height set in pixels due to the above jQuery. To address this I use Mobile Detect to add a 'mobile' class to the body of my document. And then I wrap the above jQuery in an if statement:
if ($('body').hasClass('mobile')) {
var viewportHeight = $('.banner').outerHeight();
$('.banner').css({ height: viewportHeight });
}
As a result, if a user is on a mobile device the class 'mobile' is present on the body of my page and the above jQuery is executed. So my banner element will only get the inline CSS applied on mobile devices meanwhile on desktop the original 100vh CSS rule remains in place.
I came up with a React component – check it out if you use React or browse the source code if you don't, so you can adapt it to your environment.
It sets the fullscreen div's height to window.innerHeight and then updates it on window resizes.
As I was looking for a solution some days, here is mine for everyone using VueJS with Vuetify (my solution uses v-app-bar, v-navigation-drawer and v-footer):
I created App.scss (used in App.vue) with the following content:
.v-application {
height: 100vh;
height: -webkit-fill-available;
}
.v-application--wrap {
min-height: 100vh !important;
min-height: -webkit-fill-available !important;
}
You can try giving position: fixed; top: 0; bottom: 0; properties to your container.
#nils explained it clearly.
What's next then?
I just went back to use relative 'classic' % (percentage) in CSS.
It's often more effort to implement something than it would be using vh, but at least, you have a pretty stable solution which works across different devices and browsers without strange UI glitches.
The the problem still remains to this date, unfortunately. And the biggest misleading it's impossible to represent the situation by using browser's devices toolbar.
I've just solved the issue like so (tested on PC, iOS and android browsers):
.your_class {
height: 100vh,
max-height: 100%, // <-- add the line
...some other props,
}
I hope it'll save your time.
The following code solved the problem (with jQuery).
var vhHeight = $("body").height();
var chromeNavbarHeight = vhHeight - window.innerHeight;
$('body').css({ height: window.innerHeight, marginTop: chromeNavbarHeight });
And the other elements use % as a unit to replace vh.
As I am new, I can't comment on other answers.
If someone is looking for an answer to make this work (and can use javascript - as it seems to be required to make this work at the moment) this approach has worked pretty well for me and it accounts for mobile orientation change as well. I use Jquery for the example code but should be doable with vanillaJS.
-First, I use a script to detect if the device is touch or hover. Bare-bones example:
if ("ontouchstart" in document.documentElement) {
document.body.classList.add('touch-device');
} else {
document.body.classList.add('hover-device');
}
This adds class to the body element according to the device type (hover or touch) that can be used later for the height script.
-Next use this code to set height of the device on load and on orientation change:
if (jQuery('body').hasClass("touch-device")) {
//Loading height on touch-device
function calcFullHeight() {
jQuery('.hero-section').css("height", $(window).height());
}
(function($) {
calcFullHeight();
jQuery(window).on('orientationchange', function() {
// 500ms timeout for getting the correct height after orientation change
setTimeout(function() {
calcFullHeight();
}, 500);
});
})(jQuery);
} else {
jQuery('.hero-section').css("height", "100vh");
}
-Timeout is set so that the device would calculate the new height correctly on orientation change. If there is no timeout, in my experience the height will not be correct. 500ms might be an overdo but has worked for me.
-100vh on hover-devices is a fallback if the browser overrides the CSS 100vh.
I just found a web app i designed has this issue with iPhones and iPads, and found an article suggesting to solve it using media queries targeted at specific Apple devices.
I don't know whether I can share the code from that article here, but the address is this: http://webdesignerwall.com/tutorials/css-fix-for-ios-vh-unit-bug
Quoting the article: "just match the element height with the device height using media queries that targets the older versions of iPhone and iPad resolution."
They added just 6 media queries to adapt full height elements, and it should work as it is fully CSS implemented.
Edit pending: I'm unable to test it right now, but I will come back and report my results.
Do not use recommended approaches such as -webkit-fill-available.
I just spent all day rushing around to fix this "bug".
Add a class when your app is loaded with a browser with a "chin".
JavaScript
// Angular example but applicable for any JS solution
#HostBinding('class.browser-has-chin') browserHasChin: boolean = false;
public ngOnInit(): void {
this.browserHasChin = this._isMobileSafari();
}
private _isMobileSafari() {
return navigator.userAgent.match(/(iPod|iPhone|iPad)/) && navigator.userAgent.match(/AppleWebKit/) ? true : false;
}
CSS
.browser-has-chin {
#media screen and (max-device-width: 767px){
// offset with padding or something
}
}
NOTES:
There are major issues with the -webkit-fill-available prop for cross-browser compatibility.
I was able to get it working in Chrome and iOS Safari to fix the chin/height calculation issue. However it broke Android Chrome and Firefox had bugs with it too.
It seems that -webkit-fill-available was rushed into webkit at some point and perhaps adopted haphazardly by Apple as a fix for chin/height calculation?
It relies on intrinsic sizing which is NOT safe to use yet.
I have created two examples below:
To showcase how height: 100vh as height can lead to scroll in mobile chrome browsers:
code : https://codesandbox.io/embed/mobile-viewport-100vh-issue-nxx8z?fontsize=14&hidenavigation=1&theme=dark
demo: https://nxx8z.csb.app/
Solution using position: fixed to resolve the issue and with purely CSS:
code : https://codesandbox.io/s/mobile-viewport-100vh-issue-fix-forked-ypx5x?file=/index.html
demo : https://ypx5x.csb.app/
The VH 100 does not work well on mobile as it does not factor in the iOS bar (or similar functionality on other platforms).
One solution that works well is to use JavaScript "window.innerHeight".
Simply assign the height of the element to this value e.g.
$('.element-name').height(window.innerHeight);
Note: It may be useful to create a function in JS, so that the height can change when the screen is resized. However, I would suggest only calling the function when the width of the screen is changed, this way the element will not jump in height when the iOS bar disappears when the user scrolls down the page.
React hooks solution with useEffect and useState
function App() {
const [vh, setVh] = useState(window.innerHeight);
useEffect(() => {
const updateVh = () => {
setVh(window.innerHeight);
};
window.addEventListener('resize', updateVh);
return () => window.removeEventListener('resize', updateVh);
}, []);
return (
<div style={{ height: vh }}>
{vh} px
</div>
);
}
Demo: https://jsfiddle.net/poooow/k570nfd9/
Because it won't be fixed, you can do something like:
# html
<body>
<div class="content">
<!-- Your stuff here -->
</div>
</body>
# css
.content {
height: 80vh;
}
For me it was the fastest and more pure solution than playing with the JavaScript which could not work on many devices and browsers.
Just use proper value of vh which fits your needs.
The following worked for me:
html { height: 100vh; }
body {
top: 0;
left: 0;
right: 0;
bottom: 0;
width: 100vw;
}
/* this is the container you want to take the visible viewport */
/* make sure this is top-level in body */
#your-app-container {
height: 100%;
}
The body will take the visible viewport height and #your-app-container with height: 100% will make that container take the visible viewport height.
Using vh on mobile devices is not going to work with 100vh, due to their design choices using the entire height of the device not including any address bars etc.
If you are looking for a layout including div heights proportionate to the true view height I use the following pure css solution:
:root {
--devHeight: 86vh; //*This value changes
}
.div{
height: calc(var(--devHeight)*0.10); //change multiplier to suit required height
}
You have two options for setting the viewport height, manually set the --devHeight to a height that works (but you will need to enter this value for each type of device you are coding for)
or
Use javascript to get the window height and then update --devheight on loading and refreshing the viewport (however this does require using javascript and is not a pure css solution)
Once you obtain your correct view height you can create multiple divs at an exact percentage of total viewport height by simply changing the multiplier in each div you assign the height to.
0.10 = 10% of view height
0.57 = 57% of view height
Hope this might help someone ;)
Here's a work around I used for my React app.
iPhone 11 Pro & iPhone Pro Max - 120px
iPhone 8 - 80px
max-height: calc(100vh - 120px);
It's a compromise but relatively simple fix
A nice read about the problem and its possible solutions can be found in this blog post: Addressing the iOS Address Bar in 100vh Layouts
The solution I ended up in my React application is utilising the react-div-100vh library described in the post above.
Brave browser on iOS behaves differently (buggy?). It changes viewport height dynamically accordingly to showing/hiding address bar. It is kind of annoying because it changes page's layout dependent on vw/vh units.
Chrome and Safari is fine.
I solved it by putting the most outer div at position: absolute and then just setting the height to 100%:
CSS:
.outer {
position: absolute;
height: 100%;
}
HTML:
<div class="outer">
<!-- content -->
</div>
It seems like CSS fix is unreliable and JS one works fine but the element is jumping when user opens the page.
I solved the issue using JS from other answers + fadeIn animation to hide jumping.
This won't fit all the use cases, but for some of them, like a button that has to be at the bottom, could be a good solution.
The people who found this answer and are struggling with an issue of wiered jumping of elements on mobile view when scrolling downward/upward whose position is fixed w.r.t the root element need to specify the property in terms of bottom rather than top and should give a field value in px. This solves the issue
change this:
element{
position: fixed;
top: 90vh;
left: 90vh;
transform: translate(-95%, -95%);
}
to this:
element{
position: fixed;
bottom: 90px; /* this is the change */
left: 90vh;
transform: translate(-95%, -95%);
}
This question already has answers here:
Prevent scroll-bar from adding-up to the Width of page on Chrome
(20 answers)
Prevent a centered layout from shifting its position when scrollbar appears
(7 answers)
Closed 5 years ago.
Many programmers have asked how to stop their web page content — especially their centered web page content (margin: 0 auto;) — from shifting (being pushed) horizontally when the vertical scroll bar appears. This has been an ongoing problem for Ajax users and people like me who use hidden divs and tabs to organize data.
The problem occurs when the currently displayed page changes such that the height of the displayed material (the inner window height) is suddenly greater than the physical window height.
The problem is exacerbated by the reality that all scrollbars are not created equal. Different browsers give their scroll bars different widths, and that difference cannot (or, at least, should not) be predicted. In short, the ideal solution is scrollbar width independent.
This, therefore, is a self-answered question that rolls all those answers with commentary on their usefullness (where possible) along with my own solution into a single answer as of August 5, 2017. I've marked as duplicates as many of the previous questions as I can find so that people can find a comprehensive discussion of the issue.
Please note that this answer addresses problems with BODY contents shifting. If you have a DIV with a fixed height that has shifting problems, you should set the DIV width to a fixed (px) width so its scrollbar floats above the text and add some right-hand padding to keep the text from falling beneath it. Contributors: Hashbrown,
Avrahamcool,
Edward Newsome
Before going into individual solutions, it should be mentioned that they break down into three categories: CSS-, CSS3-, and Javascript-based solutions.
The CSS solutions tend to be rigid but very predictable and very well supported.
The CSS3 solutions have a CPU calculation cost like Javascript, but are easy to implement. In years previous to 2017, however, they had sporadic support in browsers. That is improving over time. Ultimately, they will likely be the best solution, but my own investigations today have demonstrated the support simply isn't consistent enough yet and, besides, legacy browser support is non-existent.
The Javascript solutions (whether in straight Javascript or in jQuery) need extra coding to make them robust as they have no intrinsic support for (e.g.) window resizing. However, they're the most predictable and the most backward compatible while still preserving the aesthetics of the page. I consider the line for legacy browsers to be between IE6 and IE7. Frankly, my condolences to anyone still using a browser that old.
Please note that I have not included every CSS3 and Javascript solution previously posted to Stack Exchange. Some, though novel, had substantial weaknesses and so were not included here.
**Solution #1: The CSS Solution**
Contributors: Hive7, koningdavid, Christofer Eliasson, Alec Gorge, Scott Bartell, Shawn Taylor, mVChr, fsn, Damb, Sparky, Ruben, Michael Krelin - hacker, Melvin Guerrero
Force the srollbar to always be on.
<style>
html {
overflow-y: scroll;
}
</style>
This solution is basically guaranteed to always work (there are some exceptions, but they're very rare), but it is aesthetically unpleasing. The scrollbar will always be seen, whether it's needed or not. While concensus is to use this solution in the html tag, some people suggest using it in the body tag.
Consequences
Microsoft (IE10+) has implented floating scroll bars which means your page may not be centered in it like it would be in other browsers. However, this seems to be a very minor issue.
When using structured interfaces like FancyBox, Flex-Box, or Twitter Bootstrap Modal this can cause a double-scrollbar to appear as those interfaces create their own scrollbars.
Programmers should avoid using overflow: scroll as this will cause both the vertical and horizontal scrollbars to appear.
Solution #1a: An Alternative
Contributors: koningdavid, Nikunj Madhogaria
A clever alternative, but one having only a minor aesthetic difference, is to do this:
<style>
html {
height: 101%;
}
</style>
This activates the scroll bar background but doesn't activate the scroll bar tab unless your vertical content actually overflows the bottom edge of the window. Nevertheless, it has the same weakness in that the scrollbar space is permanently consumed whether needed or not.
Solution #1b: A More Modern Solution
Contributors: Kyle Dumovic, SimonDos
Browsers are beginning to pick up the use of the overlay value for scrollbars, mimicking the floating scrollbar of IE10+.
<style>
html {
overflow-y: overlay;
}
</style>
This solution mimics the floating scrollbar in IE10+, but it is not yet available in all browsers and still has some implementation quirks. This solution is known not to work for infrastructure environments like Bootstrap Modal.
**Solution #2: The CSS3 Solution**
Use CSS3 to calculate widths. There are many ways to do this with advantages and disadvantages to each. Most disadvantages are due to (a) not knowing the actual scrollbar width, (b) dealing with screen resizing, and (c) the fact that CSS is slowly becoming yet-another-fully-functioning-programming language — like Javascript — but has not yet completely evolved into such. Whether or not it even makes sense for it to become such is a debate for another question.
The argument that users may disable Javascript and so a CSS-only solution is preferable is becoming irrelevant. Client-side programming has become so ubiquitous that only the most paranoid of people are still disabling Javascript. Personally, I no longer consider this a tenable argument.
It should be noted that some solutions modify margin and others modify padding. Those that modify margin have a common problem: if you have navigation bars, headers, borders, etc. that use a different color than the page background this solution will expose undesirable borders. It is likely that any solution using margin can be re-designed to use padding and vice-versa.
Solution #2a: The HTML-based Solution
Contributors: TranslucentCloud, Mihail Malostanidis
<style>
html {
margin-left: calc(100vw - 100%);
margin-right: 0;
}
</script>
Solution #2b: The BODY-based Solution
Contributors: Greg St.Onge, Moesio, Jonathan SI
<style>
body {
padding-left: 17px;
width: calc(100vw - 17px);
}
#media screen and (min-width: 1058px) {
body {
padding-left: 17px;
width: calc(100vw - 17px);
}
}
</style>
100vw is 100% of the viewport width.
Consequences
Some users have suggested this solution creates undesirable screen noise when the window is resized (perhaps the calculation process is occuring multiple times during the resize process). A possible workaround is to avoid using margin: 0 auto; to center your content and instead use the following (the 1000px and 500px shown in the example represent your content maximum width and half that amount, respectively):
<style>
body {
margin-left: calc(50vw - 500px);
}
#media screen and (max-width: 1000px) {
body {
margin-left: 0;
}
}
</style>
This is a fixed-scrollbar-width solution, which isn't browser independent. To make it browser independent, you must include Javascript to determine the width of the scrollbars. An example that calculates the width but does not re-incorporate the value is:
Please note that the code snippet below has been posted multiple times on Stack Exchange and other locations on the Internet verbatim with no firm attribution.
function scrollbarWidth() {
var div = $('<div style="width:50px;height:50px;overflow:hidden;position:absolute;top:-200px;left:-200px;"><div style="height:100px;"></div>');
// Append our div, do our calculation and then remove it
$('body').append(div);
var w1 = $('div', div).innerWidth();
div.css('overflow-y', 'scroll');
var w2 = $('div', div).innerWidth();
$(div).remove();
return (w1 - w2);
}
Solution #2c: The DIV-based Solution
Contributors: Rapti
Use CSS3 calculations applied directly to a container DIV element.
<body>
<div style="padding-left: calc(100vw - 100%);">
My Content
</div>
</body>
Consequences
Like all CSS3 solutions, this is not supported by all browsers. Even those browsers that support viewport calculations do not (as of the date of this writing) support its use arbitrarily.
Solution #2d: Bootstrap Modal
Contributors: Mihail Malostanidis, kashesandr
Users of Twitter Bootstrap Modal have found it useful to apply the following CSS3 to their HTML element.
<style>
html {
width: 100%;
width: 100vw;
}
</style>
Another suggestion is to create a wrapper around your content wrapper that is used to auto-detect changes in the viewport width.
<style>
body {
overflow-x: hidden;
}
#wrap-wrap {
width: 100vw;
}
#content-wrap {
margin: 0 auto;
width: 800px;
}
</style>
I have not tried either of these as I do not use Bootstrap.
**Solution #3: The Javascript Solution**
Contributors: Sam, JBH
This is my favorite solution as it deals with all the issues and is reasonably backward compatible to legacy browsers. Best of all, it's scrollbar-width independent.
<script>
function updateWindow(){
document.body.style.paddingLeft = (window.innerWidth - document.body.clientWidth);
document.body.onclick=function(){
document.body.style.paddingLeft = (window.innerWidth - document.body.clientWidth);
}
}
window.onload=updateWindow();
window.addEventListener("resize", updateWindow());
updateWindow();
</script>
Consequences
The final command to updateWindow(); should occur just before the </body> tag to avoid problems with dynamically-loaded content such as Facebook Like-Boxes. It would seem that it's redundant to the window.onload event, but not every browser treats onload the same way. Some wait for asynchronous events. Others don't.
The function is executed each and every time a user clicks within the web page. Gratefully, modern computers are fast enough that this isn't much of an issue. Still….
Finally, the function should be executed after any div is asynchronously updated (AJAX). That is not shown in this example, but would be part of the ready-state condition. For example:
xmlhttp.onreadystatechange=function(){
if(xmlhttp.readyState==4 && xmlhttp.status==200){
if(xmlhttp.responseText == 'false'){
//Error processing here
} else {
//Success processing here
updateWindow();
}
}
}
Solution #3a: Measuring Scrollbar Widths
Contributors: Lwyrn
This is a less valuable solution that takes the time to measure scrollbar widths.
<script>
var checkScrollBars = function(){
var b = $('body');
var normalw = 0;
var scrollw = 0;
if(b.prop('scrollHeight')>b.height()){
normalw = window.innerWidth;
scrollw = normalw - b.width();
$('#container').css({marginRight:'-'+scrollw+'px'});
}
}
</script>
<style>
body {
overflow-x: hidden;
}
</style>
Consequences
Like other solutions, this one permanently disables the horizontal scrollbar.
It looks like with the new version 3.0 I have to set the class names of an image to col-lg-4 col-sm-4 col-4 if the image is part of div with the same class names to make the image responsive with all breakpoints.
In version 2 the images CSS properties inherited by default the parent's div properties.
Is this correct?
Bootstrap 4
For Bootstrap 4 use Sass (SCSS):
// make images responisve by default
img {
#extend .img-fluid;
}
answer updated for version 3
Bootstrap 3 has a special class for responsive images (set max-width to 100%). This class is defined as:
.img-responsive {
display: block;
height: auto;
max-width: 100%;
}
Note img tag gets by default:
img {
vertical-align: middle;
border: 0;
page-break-inside: avoid;
max-width: 100% !important;
}
So use class="img-responsive" to make your images responsive.
To make all images responsive by default:
css: add the code below under the bootstrap css:
img {
display: block;
height: auto;
max-width: 100%;
}
less: add the code below in your mixins.less:
img {
&:extend(.img-responsive);
}
Note: requires Less 1.4.0. see: https://stackoverflow.com/a/15573240/1596547
Carousel
img tags inside a carousel are responsive by default
Semantic rules
See also the answer of #its-me (https://stackoverflow.com/a/18653778/1596547). Using the above to make all your images responsive by default turns your images to block level elements. Block level elements are not allowed in paragraphs (<p>), see: https://stackoverflow.com/a/4291515/1596547
As far as i understand the distinction of block-level vs. inline elements is replaced with a more complex set of content categories. See also: https://developer.mozilla.org/en-US/docs/Web/HTML/Inline_elemente#Inline_vs._block-level.
So in HTML5 a p tag can contain any phrasing element intermixed with normal character data. (see: http://www.w3.org/TR/html-markup/p.html) The img tag is such a phrasing element. The img tag's default value for the display property is indeed inline-block. Changing the display property to block does not violate any of the preceding rules.
Block level elements (display:block) take all the available space of their parent, which seems exactly what you expect for responsive images. So setting display: block; seems a reasonable choice, which has to be preferred above the inline-block declaration.
Images inside p elements which require inline-block as suggest by #its-me (https://stackoverflow.com/a/18653778/1596547) should maybe not be responsive at all.
Excellent suggestion by #BassJobsen, but I'd use display: inline-block; instead of display: block; as that feels more semantic 1 (which means you can be a bit more sure you are not messing up somewhere else).
So, mine would look like this:
img {
display: inline-block;
height: auto;
max-width: 100%;
}
Please do let me know if my understanding is flawed. :)
[1]: For one, images are almost always wrapped in a block-level element if that's the use case; and then again, we also use images in elements like paragraphs (p), where an inline-block would be more appropriate than a block element.
Got here after trying to figure out if it's safe to apply img-responsive for all images.
The answer by #its_me led me to think that it isn't safe to apply this for images under a p element.
This does not seems to be what the bootstrap team think.
This is why images are not responsive by default in bootstrap3:
The summary is that it breaks a ton of unsuspecting third-party widgets (including Google Maps), which understandably don't anticipate the images within them being forcibly resized to other widths. This is why we rolled back Bootstrap v2's "images are responsive by default" approach in Bootstrap v3 in favor of an explicit .img-responsive class.
https://github.com/twbs/bootstrap/issues/18178#issuecomment-154180107
I have problems to place N divs side by side with full browser width
I want like this. when you resize browser space between divs must stay same and divs must resize in width.
|div| |div| |div|
| div | | div | | div |
One solution would be to use percentages:
div.mydiv {
width: 33%;
display: inline-block;
}
If you do this, be careful with padding: that adds to a div's width, possibly causing overflow. This can be fixed if you support only IE >=8, by doing
div.mydiv {
width: 33%;
display: inline-block;
-moz-box-sizing: border-box; /* OMG why doesn't Firefox support this yet */
-webkit-box-sizing: border-box; /* Safari below 5.1, including 5 */
box-sizing: border-box;
}
And if you do that, there's even one more possible problem: space between the divs. This occurs because you have empty text nodes in between them, and display: inline-block thinks that's OK: elements laid out in an inline-type fashion can be interspersed with blank text nodes. To fix this, there's a pretty bad hack:
div.containerOfAllTheDivs {
font-size: 0;
}
div.mydiv {
font-size: 12px; /* or whatever */
/* plus the above stuff */
}
This makes it so that any text (e.g. whitespace) that appears inside the container is zero-sized, unless it appears inside the divs you are stacking next to each other, in which case it reverts back to 12px. As I said, a pretty bad hack. But it works.
The more general solution is the new flexbox proposal, but that is still under heavy revision: there are two outdated versions implemented in various browsers, with the latest one not being implemented in any as of today (2012-05-15). If you know your exact environment, though, this might be a good solution.
For two divs, just do (Demo):
div
{
width: 49%;
float: left;
}
For three, do (Demo):
div
{
width: 33%;
float: left;
}
If you need an arbitrary number of divs, you have two options:
If the number is determined by the server (value is coming from a database or a session or whatever), you can generate appropriate CSS on the server side. This solution is preferable.
If not, you need JavaScript to calculate the viewport's width, and assign width values accordingly to your divs.
The same thing could be achieved using CSS3 Flexible Box Style Layout with very less coding. Well it depends upon the browser you are planning to support.
Now Flexible box layout is supported only in webkit engines & mozilla
Putting this as an answer because I guess it's valid and may serve you well. 960.gs and bootstrap both provide scaffolding for layouts identical to what you want. 960.gs is just layout but if bootstrap suits you, you can customize it on their site to just get the bits that deal with layout. One caveat for bootstrap, I haven't found a way to remove the left margin on the div columns. 960.gs includes alpha and omega classes that set margin-left and margin-right to 0 respectivley. I had to add these to bootstrap when I used it.
Using one of those scaffoldings will save you a lot of time and effort. If you have to hand your code off to somebody else later or even just have somebody else working on it with you, using a scaffolding will help them work with your code too.
I have two layout elements lets say one is 33%, the other 66%. They both use 100% of my screen size (So it is dependent on browser window). The smaller element also has a min-size property, so it cant fall below 250px;
Now if the layout is at least 757px large (so the size where the min property doesn't apply) everything looks fine. If the layout falls below the 757px the second element starts to overflow since it still takes the 66%, so the sum of both layouts exceeds the 100%.
I made some graphics to show the behavior:
Layout 1000px not overflowing:
Layout 500px overflowing
Is there a solution to prevent the overflow (not overflow: hidden) so the second element takes only the remaining space when the first element reaches it's min width.
Also JavaScript shouldn't be used excessive!
Regards, Stefan
Sure, this is actually pretty easy and requires a very minimal amount of code:
HTML:
<div class="sidebar">
...
</div>
<div class="content">
...
</div>
CSS:
.sidebar{
float: left;
width: 33%;
}
.content {
overflow: hidden; /* Ensures that your content will not overlap the sidebar */
}
You can view the live demo here: http://jsfiddle.net/7A4Tj/
Edit:
If you're trying to achieve a site layout that has equal-height background images for the sidebar and content, all you need to do is wrap both those elements in a containing div and use the Faux Columns technique.
Try using the following for the second widget:
position: fixed;
right: 0;
Here´s my five cents
min-width on both divs
and a wrapper that also has min-width, plus both of the divs having percentage width
JS fiddle code
PS seems to be working fine in IE8
PPS Also do check out #media queries if you want to have conditional CSS rules on different window sizes, might be helpful. Will run on browsers supporting CSS3: CSS Media queries at CSS Tricks