My basic CSS rule for font-size
and line-height
is pretty simple:
body {
font-family: Arial, Helvetica, sans-serif;
font-size: 16px;
line-height: 24px;
}
When I create a paragraph that contains an <em>
or a <strong>
开发者_JAVA技巧(or even some <code>
which uses a different font-size
than the <body>
), I notice that these elements increase the line-height by a pixel or two.
This leads me to believe that most browsers take the largest inline element to display line-height
. Is that right?
My goal is to make the line-height
consistent, regardless of which elements are inline.
The only way I've found to make the line-height
consistent is to define:
em, strong, code, etc {
line-height: 100%;
}
Is this the right way to go about this? Or am I being too much of a perfectionist?
Edit 1:
This also seems to work:
em, strong, code, etc {
line-height: 1;
}
Edit 2:
After playing with this for a few days, it doesn't appear that there is a reliable solution for keeping a consistent line-height
. If anyone has any ideas, I'd certainly love to hear them.
Edit 3:
For my own future reference and from my own research, these tags should be considered with line-height: 1
as long as they are displayed inline along with other standard body text:
abbr, acronym, b, big, cite, code, del, dfn, em, i, ins, kbd, q,
samp, small, strong, sub, sup, tt, var
These elements are questionable:
a, bdo, img, span
The spec confirms what you thought, that browsers take the largest font for the line-height calculation. That means your only option (and the one the spec mentions) is to set the line height for ALL the inline boxes on lines you care about. You probably would not be happy with the results of selecting body *
and setting the font size. So add some Divs with the same class around whatever blocks of text you want to look uniform, and there you go:
div.uniformlines * {
line-height: 100%;
font-size: 16px;
}
It seems best and most flexible to define body {line-height: 0}
then define the line-height for major content areas with line-height: 1
or 1.5 or whatever. That allows you to control the other elements more dynamically and consistently.
For example, line-height can be really problematic for images or other grids that want to be aligned flush with each other, like a gallery-style. This is most often the case when images have anchor tags, which inherit the line-height of its parent. The spec allows for a "normal" value, but that seems to be a different standard per browser. 1 or 100% are also options, but "0" seems to basically make all browsers force the same standard, like a good CSS reset. Of course all text gets squished to one line with "0", that's why setting the line-height at the content areas is necessary.
Here's a codepen I put together to illustrate the point
This thread is already years old and things might have changed in the meantime, but the following (which i rediscovered on http://webdesignandsuch.com/how-to-fix-sup-sub-line-height-problem-with-css/ (archive)) works for me:
* {
vertical-align: bottom; }
It's quite surprising since vertical-align
as such would seem unrelated to line-height
; then again, this is CSS so you never know. The website quoted above in fact suggests
sub {
height: 0;
line-height: 1;
vertical-align: baseline;
_vertical-align: bottom;
position: relative; }
which looks like a hack to me.
I think that's a pretty neat idea.
However, don't forget that if the bold/italic text is too large then you could impair readability by making all the lines really tall when only one needs to be. You may also want something to deal with superscript and subscript, if your example doesn't already take care of it.
I'm not seeing this behavior, but I'm using WebKit. Does the problem happen for you if you throw some bold tags into this example?
http://www.w3schools.com/css/tryit.asp?filename=trycss_line-height
精彩评论