I noticed that line-height seems to affect blocks. Its strange to me, that i never noticed this disturbing effect before.
The problem is that it will affect blocks, even if they do not contain text at all.
I created a JSFiddle to demonstrate the issue. If you set line-height to 0, the grey area will no longer exceed that of the image inside the container.
Why is this happening and is there a clean way to prevent it?
The line-height value affects rendering even in the absence of text, since “'line-height' specifies the minimal height of line boxes within the element. The minimum height consists of a minimum height above the baseline and a minimum depth below it, exactly as if each line box starts with a zero-width inline box with the element's font and line height properties.” (CSS 2.1 about line-height.)
But that’s really not the cause here. Images are by default rendered inline, meaning that they act as big (or maybe small) letters, sitting on the baseline of text. The details are complicated, but by setting line-height considerably smaller than font size, you put baselines closer to each other and the space vanishes.
Another way to remove the disturbing effect is to set display: block on the img element. Then the element will be formatted in a different way.
Yet another way is to set vertical-align: bottom on the img element.
Related
<p class="main-title">text here</p>
So, my error is, that this simple line of code always gets 100% width for no reason. The same is for all my text elements. The Container it is in hasnt got any display state (so block) that could make the error.
If I set the width to like 150px there is something like margin still there.
Thanks for your help
Most browsers will display the p element as block. And block elements, by default, don't stack on the same line than others.
So even if you put it at width 150px, the next element will always go next line.
To solve it either :
display your p as inline-block (or just inline if you don't need to resize it)
replace your p with span
use float to ask that your blocks stop pushing others
See My Fiddle:
http://jsfiddle.net/5BEsZ/
I've discovered something very strange that I haven't seen documented anywhere else... Was wondering if you all had a solution.
You'll notice the negative margin hits a limit at around -212% for image elements. Is there a reason for this? Can you think of a work around?
Why I Need This (what I've tried):
I'm making a fluid layout and I want to display a rating system. I have a sprite sheet of stars (similar to the one in the fiddle) that I want to reuse at various sizes.
Because the size changes I can't use a background image. So I decided to use an image inside a container with a variable width and overflow:hidden. The sprite sheet adjusts to the width of the container and the container's viewable content is determined by a padding-top:20%. This is so it can be fluid with its width (since every star is a box, the total height is 20% the width).
Then I try and position the star image inside the container with margin-top. I tried using position:relative and a top:-X%, but because the container technically has no height this was causing issue on mobile phones (-100% of 0 is 0, etc).
So I assumed negative margin would work, but then discovered this strange issue!
NOTE: Because it affects only the last row I can make it work in my situation by using a padding-bottom instead of top (thereby bumping every star row up 1), but this isn't an adequate solution for me because it just ignores the problem. What if I wanted quarter stars?
I've updated your fiddle. img tags are "inline" elements by default, which impacts the way margin is calculated relative to the containing element. By forcing the image element to be rendered like a block (display: block), you're able to achieve the results you were expecting. A div element is a block by default.
As a side note, you'll want to avoid using inline styles (a different sort of "inline"!) wherever possible. Typically your styles would be included in a stylesheet instead of in a style attribute directly on the element. I included the fix (display: block) in the attribute to match the code style of your html.
I don't know why, but if you float the image the problem goes away.
<img src="http://www.whitepages.com/common/images/sprite_stars.gif?1343868502" id="stars" style="width:100%; float: left;" />
So, the answer to fix your problem: http://jsfiddle.net/5BEsZ/2/
If anyone could explain why this happens?
I have been inspecting a header element using firebug, and have noticed that the header container does not hug its contained text, even though I have no padding set.
<h2>test</h2>
http://jsfiddle.net/BTwk6/
The top and bottom spacing is greater than that on the left and right, the result of this is that my h2 does not sit squarely in its containing box.
Is this normal? Is there anyway to have the h2 box hug its text?
Thanks
Yes, it is normal, and things are supposed to be that way. If you e.g. set a border on a heading element, you will see that characters in the heading text will normally not touch the border.
There are two reasons to this. First, the height of a font is a design concept and does not (normally) correspond to the height of any letter; there is empty space above even capital letters as well as below the baseline of text. Descenders like that of “j” or “g” may, in some designs, reach the bottom of the font, and diacritic marks like that of “Ê” may reach the top, or even go beyond it.
Second, there is normally some leading above and below a line, typically a total of 15–20% of the font height. The default depends on the font (and on the browser). In practice, this is meant improve readability and to prevent characters from touching characters on the previous or next line.
The leading is indirectly set by setting line-height, since line-height sets the total height that is the sum of font height (font size) and leading. By setting line-height: 1, you set leading to zero; this is called “setting solid” in typography, and it can be suitable for isolated lines, like a one-line heading. But there is still spacing caused by the first reason mentioned, the spacing that has been “built in” into the font. You can even set line-height to a smaller value, like 0.85, making the leading negative. Beware that this may cause vertical truncation of characters if the font used differs from the one you suggest on your page.
Try adjusting the line-height property as well, by default different fonts have different spaces above and below them. You may not be able to entirely fix this. For example, the word
Tempura
Is a whole lot taller than the word
mum
But the word 'mum' will still have to have the same height above and below the line as 'Tempura'.
by default a h2 element has a margin of 19px top an bottom. Try to reset it
Try to reset margin and padding :
h2{margin:0;padding:0}
replace 0 with your own values ...
mimiz
I'm having trouble figuring out why inline elements ignore line-height in some browsers (Chrome and Firefox ignore it, but IE9 does not).
Here is an example:
<small style="line-height: 1; font-size: 26px;">Hello, World</small>
The expected result is for the element height to be 26px, however, it's being set to 31px. If I set the element's display to block, the height is correctly set to 26px.
Everything I read says it's supposed to be set to the line height, so I can't figure this one out. Here is what I read on W3C:
The height of each inline-level box in the line box is calculated. For replaced elements, inline-block elements, and inline-table elements, this is the height of their margin box; for inline boxes, this is their 'line-height'.
Source: http://www.w3.org/TR/CSS2/visudet.html#line-height
What webkit inspector shows (and what you measured in PhotoShop) is the content area's dimensions.
See http://www.w3.org/TR/CSS2/visudet.html#inline-non-replaced
The height of the content area [of inline elements] should be based on the font, but this specification does not specify how. A UA may, e.g., use the em-box or the maximum ascender and descender of the font...
Different browsers simply use a different approach here. See http://jsfiddle.net/ejqTD/1/ for an illustration of that. Note how webkit renders a higher content area, but line-height is still correct.
The content area exceeds the line box in this case, which is permitted: http://www.w3.org/TR/CSS2/visudet.html#leading
if the height specified by 'line-height' is less than the content height of contained boxes, backgrounds and colors of padding and borders may "bleed" into adjoining line boxes.
It's easy to see if you consider line-heights < 1: http://jsfiddle.net/KKMmK/
I could post the code if it would be helpful (but it's a lot). Basically, if I change line-height or font-size to a really big value, it breaks my html layout - specifically, my DIVs seem to be getting bigger...But I don't have text in those divs.
Any inline element will pay attention to line-height:
On a block container element whose content is composed of inline-level elements, 'line-height' specifies the minimal height of line boxes within the element.
In your case, you have <img> elements (which are inline elements by default) inside your <div> elements (which are block containers).
Changing the font-size implicitly alters the pixel value of line-height, the default is line-height: normal and that means:
Tells user agents to set the used value to a "reasonable" value based on the font of the element.
So, altering either the font-size or line-height will change the vertical space that your inline elements occupy.