I'm using an image which must auto-scale inside a div whose height is defined by the root div.
The scaling is fine in all major browsers, using height: 100% on the image itself.
But it seems that on some browsers, the image container doesn't adapt its width accordingly to its content (the image).
Check by yourself the live demo.
This demo uses an image container with a blue background.
Expected behavior: This background shouldn't display since the container width and height should be the same as its content (the image).
Actual behavior:
On Chrome 11, Safari 5 and IE9, the behavior is as expected.
(source: imgh.us)
On Firefox 3.6/4.0 and Opera 11, the behavior is not as expected: the blue background is displayed.
(source: imgh.us)
What is the root cause of this strong difference between major browsers?
In the case of Firefox, this looks like a bug. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=653739
You can work around by removing the overflow:hidden unless you actually need it.
Those later browsers interpret inline-block more strictly (correctly).
That is, your element is positioned inline (like a span), but the element's contents are laid out as if the element were a block.
Related
I asked this question about sub tag:
Using <sub> tag and preserve line-height
So now i use position: relative; and smaller font to "emulate" behaviour of subscript. But I have found that this solution is not pixel perfect. <div> with this emulated sub tag can have bigger height then <div> without this emulated sub tags, even when texts in each line line of divs are exactly the same. I observed this behaviour in Chrome and Firefox, here is the problem shown on live code:
http://jsfiddle.net/FRkQ6/
On my Chrome browser in Mac the output is:
Height of first div is: 163
Height of first div is: 162
This live code works on chrome on mac where both divs have the same lines with same text. On Firefox this demo does not work, because texts in lines are differently rendered. But the problem is similar to Chrome.
Can somebody explain me this behaviour? Is it some bug in browsers or intended behaviour? Can I fix that somehow with CSS (if i subtract height of top and bottom border, which is 2, height should be divisible by line-height, which is 20 in my demo, so I should never get height of 163)?
Even though the span is position:relative the browser is still (wrongly) considering its line height. Adding a line height of zero fixes it...
line-height: 0;
jsFiddle demo
In all major browsers: as the question states, a parent <div> container (whose height is not set) over-sizes its height to fit a child <img> element (for instance, a 300-pixel tall image that is the only thing inside the div). The over-sizing is usually about 3 to 5 pixels, and appears at first as img margin-bottom or div padding-bottom might look.
However, using absolute positioning, it is clearly demonstrated that the bottom of the div is below the bottom of the imgby a few pixels. It might not ruin a website's design, but it is a hurdle to overcome in certain situations. I have made a fairly detailed fiddle demonstrating this issue here.
Why is this standard practice in web browsers?
Is this meant to compensate for something? It seems unnecessary.
Is this a bug, or a soon-to-be antiquated feature?
EDIT: Thanks to the answerers/commentators below, I know the reason is that an <img> is treated by default as CSS
display:inline which preserves whitespace around the element.
Changing it to display:block completely fixes the problem by
eliminating whitespace around the element.
Notes: This over-sizing can be averted by giving the image child element a CSS property of float:left or float:right, etc., but this is a workaround, and as such is not the answer to the question. One reason this can be problematic is if you already have other float elements layered in front of the div child image (float overlap not allowed Firefox, Opera, IE. float overlapping only seems allowed in Chrome and Safari using CSS position settings). Thanks!
Add display:block to your image. I think that will fix the problem.
See this example: http://jsfiddle.net/vrgT3/5/
I made a 250x250px parent div with overflow: auto; so scrollbars appear when the content overflows the box. I have set a blue background to make it clear when the parent is visible.
Inside the parent is a child div with red background for visibility. It has 8px black borders and box-sizing: border-box; so padding and borders are included in computing the size of the box. The child div is set to min-height: 100% and min-width: 100%.
Expected result: Child div should be the exact same size as the parent, so no blue is shown and no scrollbars appear. The computed box size (content+padding+borders) should be 250x250px. There should be 8px black borders inlaying this, leaving a 234x234px red region.
Works with:
Midori 4.1 Ubuntu
Chromium 16 Ubuntu
Opera 11.61 Ubuntu
Issues with:
IE 8 WinXP: Horizontal and vertical scrollbars appear. The content is 249x266px with 8px borders giving a computed box size of 265x282px.
Firefox 3.6 WinXP: Vertical scrollbar appears. The content is 217x250px and computed box size is 233x266px.
Firefox 10 Ubuntu: Vertical scrollbar appears, content is 221x250px, computed box size is 237x266px.
I have checked caniuse.com and it appears that at least the browsers in question support the required min-height, min-width, and box-sizing. What gives?
Solution: As Marat suggested, this is indeed a browser bug. I've resolved a workaround utilizing JavaScript to add padding/margins to correct for differences in offsetWidth/Height. See it here: http://jsfiddle.net/vrgT3/8/
This is unfortunate bug of Firefox (see bug 308801) and IE8 (IE9 works correctly).
The bug is fixed in Firefox 17+.
Code:
http://www.webdevout.net/test?0U
Demo:
http://www.webdevout.net/test?0U&raw
This works in most modern browsers (Safari, Chrome, Firefox, IE8/9), but doesn't work in IE7: what gives? I basically want to let the content dictate the size of the container, and I want the header to block display and take up the fill width of the container....
So if you notice, the box on the left has content, and the green box stretches to accommodate it... make sense?
I'm doing text-indent because the green boxes have text in them and are being replaced with a background-image sprite... so that part needs to stay.
Try to style the header with position:absolute and because it is going to be a background image, you can add z-index:999 to the text.
Get rid of the height declaration in your header style. If you want to change the height of the box change your font-size property.
I would like to understand CSS more and now I have an example that renders differently in two browsers and in a program called "explorer". Here is the link to the example page that I tried to clean from any disturbing details: http://csaladterapia.hu/example.html
In the latest Firefox version the image is placed inside the fieldset because it is float:right and the other elements are clear:none. In Chrome and IE the image is placed above the fieldset.
Could you help me understanding the difference?
The interpretation of Firefox is wrong, and even very strange. Floating an element should never place the element on top of other elements - it just takes them out of the document flow, puts them to the left/right on the current line. If the element following the float is not too wide, and has no 'clear' property, it will be placed on the same line.
In your example the following element is the div, which defaults to 100% width, so it can't be placed on the same line.
What Firefox is doing is very strange - even clear:left on the following element has no effect.
Reference:
http://coding.smashingmagazine.com/2007/05/01/css-float-theory-things-you-should-know/
This is a strange one, and i'm not sure what the correct behavior is here. It is due to the width of the fieldset being 95%. Removing this width attribute shows the same behavior in Firefox and Chrome.
If you want the image to appear in the fieldset then move the image to be the first element after the legend, this way you should see consistent behavior in all browsers.
Firefox tries to honor the width of this whilst maintaining the float but it seems Chrome wants to move the fieldset onto a new line due to being block and 95% width.
In this case you can change the mark-up as mentioned.