I suppose the best way to show this is in an example: jsFiddle here
Notice that the container (.overlay_inner) with the black border has padding on all sides. If you click on the button in the top right labeled "select" the container's bottom padding disappears!
This strange behavior only occurs for me in Chrome (version 13). I don't see it in IE or Firefox.
I've sort of narrowed the problem down to this block of CSS:
input[type=button]:active {
background: -webkit-linear-gradient(top, #eaeaea, #e2e2e2);
box-shadow: inset 0 0 3px #aaa;
}
Relevant part is the box-shadow. When I remove that bit of CSS, the problem doesn't occur. Doesn't make sense to me, though. Any thoughts?
EDIT: Potential work-around found. I removed the container's bottom padding and added a placeholder div at the bottom with a height equal to the padding amount removed.
Example: jsFiddle here
Feels really hackish which makes me uncomfortable since I thought I left that behind when I stopped writing for IE, but oh well ¯\_(ツ)_/¯
I managed to minify the test case to this: http://jsfiddle.net/4GfWY/8/ and I found that the requirements for this bug to occur are:
You must have a block with
overflow: auto;
position: relative;/* Or on any other block in this but over absolute one */
padding-bottom: 100px;/* Any bottom padding */
Some content that would cause a vertical scrollbar.
An inner block with position: absolute.
And if you'd then change box-shadow for this inner block, the bug occurs.
So, there can be a lot of workarounds, the best I think is: http://jsfiddle.net/4GfWY/9/
There I replaced the position: absolute to float: right (and made some other corresponding changes ), so:
One of the requirments for bug is gone, and the bug itself is gone.
If you'd have a lot of text in title, you could make it wrap: http://jsfiddle.net/kizu/4GfWY/10/ (I replaced there height to min-height), so the button wouldn't overlay the title's text.
Related
Okay. I know there are dozens of similar threads. I've checked almost each and every one and couldn't find a working solution. I've tried negative margins, min-height, max-height, absolute footer, background-color to the body, even putted overflow:hidden to all main containers in the page. Then putted clearfix class to all of the main containers, tried putting border but the border showed below this space? I also unchecked in the browser inspector the line-height property on the body, which is set to 1 and that made the white line disappear but I need that line-height and it doesn't seem like a legit solution. So..that 1px white space at the bottom still shows on some pages of these 2 sites I work on, only on Internet Explorer (latest) and MS Edge (latest). These are the links to the specific pages:
http://www.flatrocktech.com/ on Edge only and Careers page on IE & Edge (I can't post more than 2 links)
http://flatrockoutsourcing.com/services.html (on IE & Edge)
This is one of the annoying bugs I've ever encountered.
For me, on Edge and IE10, it is caused if html/body elements have a line-height anything other than 1. Also, even if it's not 1, if I have enough page content (lets say, 150% of current viewport height), the issue dissapears if page content amount is less than before mentioned.
I had this issue and thought it had to do with the parallax effect I was using. I ended up changing my height from pixels to percentage and it cleared it up without effecting anything else.
.footer {
background-image: url('images/filler4.jpg');
background-repeat: no-repeat;
height: 100%;
background-attachment: fixed;
background-size: cover;
}
This issue will happen on IE or Edge if you set heights for the footer. Remove the height and set padding like in your design for footer instead of height. Then set the footer line height to normal.
footer {
padding: 1em;
line-height:normal;
}
This question is related to these 2:
1. css - applying padding to box with scroll, bottom-padding doesn't work
2. Bottom padding not working on overflow element in non-chrome browsers
But I didn't find anywhere as to why it happens, meaning, why in Chrome(31) and Opera(18) the padding does appear, and in Firefox(26) and IE(9-10) it doesn't.
Here's my test case:
http://jsfiddle.net/eW39h/4/
A simpler example from the related question #1:
http://jsfiddle.net/rwgZu/
<div id="container">
<div id="innerBox"></div>
</div>
#container {
padding: 3em;
overflow-x: hidden;
overflow-y: auto;
width: 300px;
height: 300px;
background: red;
}
#innerBox{
height: 400px;
background: #000;
}
I'm not really looking for a fix, but to understand what exactly is the correct implementation (and which browsers got it wrong :-)).
EDIT Dec 18th, 2013
Based on the answer by Marc Audet, I dug into the specs and made a new test case.
http://jsfiddle.net/rwgZu/79/
Here it's evident that all browsers clip the overflowing box at the same point, which is the padding-edge", which is indeed in accordance to the spec:
Whenever overflow occurs, the 'overflow' property specifies whether a box is clipped to its padding edge
And still, in Chrome there's an extra padding after the inner box.
Interesting though, that adding overflowing content inside the inner box leads to unified results on all browsers:
http://jsfiddle.net/uPY8j/1/
I could not find in the specs the rules for this type of conditions, so I'm leaving the question still open for now.
I have the same issue here and instead of using :last-child div (what if last child is hidden?) and margin-bottom trick (not so nice, the scroll bar will not reach the bottom) I use this:
#container {
padding: 20px;
padding-bottom: 0;
overflow: auto;
}
#container:after {
content: "";
height: 20px;
display: block;
}
So inserting a pseudo element will ensure my extra space, so I can use it for simulating my padding bottom value.
What do you think?
JSFIDDLE HERE:
http://jsfiddle.net/z72sn0p2/2/
According to the W3 specification, overflowing content will be clipped to the edge of the padding box:
http://www.w3.org/TR/CSS21/visufx.html
FF takes the edge of the padding box to be the outer edge, which seems to be in accordance to the definition of the padding box:
http://www.w3.org/TR/CSS21/box.html
That being the case, FF seems to be closer to the spirit of the CSS specification wording, whereas Chrome seems to have decided to clip to the edge of the content box, which is the inner edge of the padding box.
To quote the specification:
The padding edge surrounds the box padding.
Does this mean the edge closer to the content box for the edge closer to the border?
I think that there is some ambiguity, leading to two interpretations. I suspect readers with an inclination towards pure mathematics and geometry may see it one way, and readers
with a legal background may argue an alternative viewpoint.
In my opinion, the description of the box model is worded such that the progression of thought is from the inner content area towards the outer margin area. That being the case, I would think that the word "surrounds" would mean to enclose the outer edge of the area. Thus, I think FF is perhaps more right, but other developers at Chrome think otherwise.
I have a big absolute div that holds a smaller relative div. The smaller div wraps an Image (png) and auto sizes with height:auto. All works fine. But on one particular site, I get 5px of extra spacing at the bottom of the smaller div after the resize, like it over calculated the height needed? I assume I'm somehow inheriting something from the site that is impacting my resize and div container.
I reworked everything, clear floats, overflow, alternate positioning, removed auto option, flow, etc, but I can't seem to get rid of that 5px extra at the bottom, and its only on that site?
My question - how do you debug your height or auto height issues, and any idea what could be causing this?
Thanx,
Chris
on the container div:
line-height: 0px; will eliminate any height increase caused by white space.
padding: 0px; will eliminate an padding along the inside of the container div.
on the image
margin: 0px will eliminate any space added around the outside of the image.
Could you point us to the site or a jsfiddle so we can get a better idea of what's going on?
As #RyanMcDonough mentioned, Chrome's Inspector is awesome. In IE, you have the IE developer toolbar. In FF you can use Firebug (which is a classic!).
Try
font-size:0;
line-height:0
for smaller div
Example http://jsfiddle.net/U9z5K/14/
Or use
display:block;
for an image
I'd use something like Chrome's Inspect Element, and have a look at the css rules that are affecting it.
You can then go through all the elements and enable/disable on the fly to see what is affecting it.
https://developers.google.com/chrome-developer-tools/
I am scratching my head for quite a long time and finally decided to ask for help. Actually I have a simple form with two inputs (field + button) and I want to bring button over field while wrapping the form to correct width of text field + padding.
I am using
margin-left: -31px
on button which is set width of 27px.
You can try it at http://jsfiddle.net/UfK6K/
and it appears
BUT when I set margin-left: -32px it breaks the layout.
http://jsfiddle.net/UfK6K/1/ and appears
Now if I change width of button to any figure and as long I keep margin-left within negative 4px difference it works but when it increases like in case of -32px it breaks.
I want to understand from where difference of 4px comes into play?
And Of course how I can move button bit more left over text field?
*It breaks in all browsers except Opera.
Well its a very tricky question that from where 4px comes from. I'll try to answer it.
When any element is set display to inline-block then 4px are found to be placed at right side of this element. Actually its the size a 'white space' takes, yes its actually a white space.
You can think of it as that inline-block element are separated by a white space and it usually takes 4px because in Opera it takes bit more (not sure about latest version though -- because different fonts render whitespace with different widths in different browsers the only font that renders a consistent white-space width across browsers and font sizes is Courier New. it is a fixed width font, and it’s whitespace is 0.63em wide.). But you get the point?
Now there are various work around like float:left or even setting negative 4px letter spacing of parent element which contains inline blocked elements.
You can also try font-size: 0;
And in your particular case position:absolute; seems to be best option.
You could add position: absolute; to the button's CSS.
.sbutton {
position: absolute;
margin-left: -30px;
margin-top: 1px;
/* ... */
}
Fiddle: jsfiddle.net/UfK6K/4
Not sure why it breaks (FF9 here). CSS positioning can cause lots of fun sometimes.
The 4px comes from the rendering of the white space between the two input fields. The button moves on to the next line because you're not leaving sufficient space for the white space to be rendered on the first line after the first input box.
The white space wraps to the next line and the button is then rendered after it, shifted by the margin-left setting.
As you've already discovered, removing the white space between the input box solves the problem. The alternative in CSS would have been to add white-space: nowrap; to the form styling.
Another way that you could do it is by adding
.sbutton {
margin-right: 5px;
margin-left: -32px;
}
and for some reason that fixes it. Then for every pixel-decrease in margin left, increase the margin right.
negative-margins have always confused me...
I have defined a fieldset in HTML, and applied the following (simple) CSS rules to it:
fieldset
{
margin: 2em 0;
position:relative;
padding: 1em;
border:1px solid #ccc;
}
Everything is great, no big deal, except in all versions (well, up to 7 as far as I know) of IE the top border -- but not, interestingly, the bottom border -- of the fieldset visually extends too far to the right by about 25px, beyond where the vertical border is on that side.
It is worth noting that this element's width causes it to be outside its parent element width-wise to the right, when viewed in Firebug for example.
What is causing this problem in IE? Is this a known issue, and, if so, what is the fix / hack / workaround?
I've struggled with this one for some time; tonight I finally found the answer.
http://www.sitepoint.com/forums/showthread.php?t=526881
To quote NatalieMac:
Seems that if you have an element inside the fieldset that's overflowing
to the right of the fieldset, it extends the top border. I had a
container set to a width of 100% with no padding or margins which IE7
thought was overflowing for some reason (even though the content inside
this container was right-aligned and viewable within the border of the
fieldset).
I was able to fix it just by adding overflow:hidden to the fieldset.
I can confirm that this does indeed fix the issue for me as well.
Could you post more of your code, like the HTML of what's surrounding the fieldset and the corresponding CSS rules for that?
You mentioned that you can see it's wider than its parent element in Firebug. That's almost certainly related. Can you change the CSS of the parent element to make it wide enough to contain the fieldset?
Without a little more context, it's probably going to be tough to diagnose this more accurately...