width: 100vw;/* 100% of viewport width */
height: 100vh;/* 100% of viewport height*/
This CSS should give me the exact(100%) dimensions of the viewport. But it is apparently too large because it's causing an overflow on the page.
It is not padding, margin, or outline because I removed all of that.
note It also seems that it only "grows" bigger than the projected dimensions when I add two divs with these dimensions. (but it's always the case in jsfiddle)
http://jsfiddle.net/0psu7ys6/
Should I just consider it a bug and write a work around? Or am I missing something?
The viewport measurements are accurate. The problem lies in the fact that your div is an inline-block. The browser renders your inline-block element on a line box. The whitespace underneath your div comes from the baseline of this line box; it is the area where typographic descenders should go. This additional space, combined with your div, is what results in overflow.
If you remove the display: inline-block declaration so that your div is rendered as a block-level element, the scrollbars will go away and the div will fit the viewport exactly.
If you need this element to be an inline-block for some reason, setting vertical-align: top (or bottom or middle) seems to fix it.
There is another way to solve this
you should set the line-height of all the body in vh
Related
I have a div, .instagram_grid which has margin-left and margin-right set to auto, is relatively positioned, and has a width which for browse sizes 900px >makes the div be centered nicely in the page.
when I have the simple structure in the context of the rest of the CSS for a single page, the no longer becomes centered at browser width >1684px. In the Fiddle that follows I only have two lines that modify the div as a whole (and one just sets the background to pink). There are no media queries present, which suggests that it is the effect of some unseen preceding div/element causing the behavior.
https://jsfiddle.net/ebbnormal/m561tpnL/6/
The behaviour is what is expected with that markup.
The element is centered, but then you use relative positioning to show it 500px to the right of where it actually would be.
The .calc-text div above the .instagram_grid div causes its parent to overflow by setting margin-left:auto while simultaneously setting left: to a negative value, which isn't valid CSS.
So I was coding using Semantic-ui, and I have two toggle boxes (check boxes) next to each other in a flexbox container. When the window size is reduced, they wrap around so that one is on top of the other.
To get them to spread out a little, I added both right and bottom padding of around 5px. However I noticed a strange behaviour. Padding would cause the boxes to move apart horizontally, but when stacked vertically there was no space between them, even though there was bottom padding on each box.
Further investigation showed that the box-sizing property of the check boxes was set to border-box. After reading up, I found that the border-box box model calculates the width and height to include the padding and the border.
The checkboxes have a height of 1.5rem assigned.
My question is as follows. As is my understanding, padding shouldn't change the size of the element when using border-box. However this only seems to be true if definite dimensions are set as shown in the linked jsfiddle. Height is set, so the bottom padding isn't added on as an extra. But width isn't and right padding has an effect on the visible width of the divs.
Why is this the case? Surely padding should have no effect on the size of the element (unless set to something ridiculous, larger than the element itself), irrespective on whether I've defined a definite width or left it to be calculated?
JSFiddle: http://jsfiddle.net/Astridax/8cd48emn/
Please try and toggle the paddings using dev tools to see what I mean.
As is my understanding, padding shouldn't change the size of the element when using border-box.
This is where you're confused. Here's what the spec has to say on this subject: http://www.w3.org/TR/css3-ui/#box-sizing0
border-box
The specified width and height (and respective min/max
properties) on this element determine the border box of the element.
That is, any padding or border specified on the element is laid out
and drawn inside this specified width and height. The content width
and height are calculated by subtracting the border and padding widths
of the respective sides from the specified ‘width’ and ‘height’
properties. As the content width and height cannot be negative
([CSS21], section 10.2), this computation is floored at 0.
The actual effect of setting box-sizing to border-box is that specified widths will be said to include the border and the padding. The spec says nothing about unspecified widths, which are therefore treated as normal - as wide as they need to be to incorporate both the content and the padding and the border.
Edit:
What you're implying should happen is actually impossible to do, for the following reason. Imagine you have content in a div such that the auto width of the content alone would be 500px exactly. Then throw a 20px padding around that.
#myDiv {
padding: 20px;
width: auto;
}
No problem yet - you have a 540px wide div with the box-sizing at content-box by default.
Okay, so lets change the box-sizing to border-box.
#myDiv {
box-sizing: border-box;
padding: 20px;
width: auto;
}
What you're suggesting should happen is that the padding should now be ignored. So we have a div with 500px worth of content, we're going to now include the padding within that 500px instead of extending the width of the div. But wait - now the content box has shrunk to 460px to allow for the padding and the overall size of the box is 500px. But wait, we're not supposed to be accounting for the padding when calculating the width, so we'd better render the div at 460px right?
You see the problem? You could go on infinitely like this.
I have overflow-x:hidden placed on the body tag of my page so that any content extending beyond the window will not be visible. No scroll bars show up, however, I can still scroll to the left / right to see the content (kinda defeats the purpose of overflow-x).
-ms-overflow-x: doesn't fix the problem either.
There is a wrapper 900px;
Inside the wrapper, there is a div inside:
width:100%;
padding-right:300px;
position:absolute;
left:200px;
I would like the inner div to hang over the right side of the window without causing it to scroll (and leaving a 200px space the its left).
Any help? Thanks!
Since the width of the div is 100%, there should never be an overflow, since the div will always fit 100% of the viewport (assuming you haven't changed the size of your body tag).
As for the padding, the padding is added on after the width, so you're saying the div is 100% of the width of it's container (the body tag), and the padding is an additional 300px to the right, which will be invisible as it's out of the viewport.
You might want to try giving the div an explicit size width and experiment that way.
It may help to see an example of your markup as well, to get an idea of what you're trying to achieve.
More HTML/CSS would be useful, but given what you have right now, my first thought is that your wrapper is still set to position: static (the default for HTML elements).
If you add position: relative to your wrapper, it will contain the absolutely-positioned element within it, and should constrain it to the overflow restrictions.
Additionally, you may want to look into the box-sizing property and how the W3C box model works. In short, your padding is adding to the width of the element, so it's actually (100% + 300px), which results in a size that is larger than the container.
If you don't want to mess with box-sizing, you can also add max-width: 100% to your absolute div to force it to not grow out of its container.
I'm noticing that display:table on a div will cause its width calculation to have rounding issues, which is odd because I am sizing at 100%.
http://jsbin.com/obidun/2/edit
Note that the upper section has a div with width of 55%, with a nested display:table div of width 100%. The nested div does not extend to the edge of its parent (note the white bleed-through of the parent div).
The lower section is exactly the same, except the nested div is not set to display:table, and there is no bleed through.
Why does display:table affect the width calculation, especially at 100%? Is there a way for me to work around this? My current thought is to just set the width to 101% and set overflow to hidden...
Note: I am using Chrome. IE seems to be okay, at least at the given size.
Percentage units are converted to pixels internally and each browser does it differently. If the solution works today, go with it, but be aware it may not apply tomorrow.
I am trying to give my div and textarea some padding. When I do this, it increases the size of the element, instead of shrinking the content area inside of it. Is there any way to achieve what I am trying to do?
You could add box-sizing:border-box to the container element, to be able to specify a width and height that don't vary when you add padding and/or border to the element.
See here (MDN) for specifications.
Update (copied comment to answer)
Right now, the value border-box is supported in all major browsers, according to MDN Specs
Some browsers of course requires proper prefix i.e. -webkit and -moz as you can clearly see here
According to CSS2 specs, the rendered width of a box type element is equal to the sum of its width, left/right border and left/right padding (left/right margin comes into play as well). If your box has a width of '100%' and also has margin, border and padding, they will affect (increase) the width occupied by the object.
So, if your textarea needs to be 100% wide, assign values to width, margin-left/right, border-left/right and padding-left/right in such a way that their sum equals 100%.
In CSS3 we have three box-sizing models. You can use border-box model:
The specified width and height (and respective min/max properties) on
this element determine the border box of the element. That is, any
padding or border specified on the element is laid out and drawn
inside this specified width and height. The content width and height
are calculated by subtracting the border and padding widths of the
respective sides from the specified ‘width’ and ‘height’ properties.
This was a mess on W3C part and various browsers only added to this complexity with their own versions of box models. Personally, instead of thinking which browser or CSS setting will do the trick I just wrap the box' content in yet another DIV statement and use margins on that DIV, instead of using padding, like this:
<div id="container" style="width: 300px; border: 10px solid red;">
<div id="content" style="width: 250px; margin: 25px;">
Some content
</div>
</div>
Although this only works for fixed size containers
It depends on the browser and it's implementation of the box model. What you are experiencing is the correct behavior.
IE traditionally got it wrong: http://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug
For a more cross-browser solution, you can avoid this behavior, by wrapping whatever tag that needs padding into another tag with fixed width, and giving it width:auto. This way, if the parent has a width of x, and you add padding to the child, the child will inherit the full width of x, applying the padding correctly without modifying the parent width or its own.
A div by default takes the width of its parent container, so to avoid browser compatibility issues, you could add a child div in the specified div then add the required padding to the child div.
N.B - don't specify width to the child div because it would increase if you add padding