473,511 Members | 15,384 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Inline-level elements: line-height, padding and background

Here are two cases regarding inline-level elements' line-height,
padding and background, which I doesn't understand:

<div style="background: black; color: white; line-height: 1.5">
<span>Abc</span>
<span style="background: white; color: black; line-height:
3">Abc</span>
<span>Abc</span>
</div>

Why doesn't the middle SPAN element have white background area tall
as 3em, but has white only behind the letters?

<div style="background: black; color: white; line-height: 1.5;
font-size: 3em">
<span>Abc</span>
<span style="background: green; color: black; padding:
0.25em">Abc</span>
<span>Abc</span>
</div>

Why in the above example the green background area crosses the top
and bottom edges of the black background area?

--
Stanimir
Jul 20 '05 #1
12 6706
/Stanimir Stamenkov/:
Here are two cases regarding inline-level elements' line-height, padding
and background, which I doesn't understand:


Eh - no real CSSers around, really!? :-)

--
Stanimir
Jul 20 '05 #2
On Tue, 06 Apr 2004 19:54:34 +0300, Stanimir Stamenkov wrote:
/Stanimir Stamenkov/:
Here are two cases regarding inline-level elements' line-height, padding
and background, which I doesn't understand:


Eh - no real CSSers around, really!? :-)


Apparently not in the 1hr 15mins
since you posted the question, no.

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology
Jul 20 '05 #3
On Tue, 06 Apr 2004 18:47:06 GMT, Andrew Thompson wrote:
On Tue, 06 Apr 2004 19:54:34 +0300, Stanimir Stamenkov wrote:
/Stanimir Stamenkov/:
Here are two cases regarding inline-level elements' line-height, padding
and background, which I doesn't understand:


Eh - no real CSSers around, really!? :-)


Apparently not in the 1hr 15mins
since you posted the question, no.


Ooops!! Try *3 days* 1hr 15mins.
Yeah, OK. Slight difference.

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology
Jul 20 '05 #4
In article <1g*******************************@40tude.net>,
Andrew Thompson <Se********@www.invalid> wrote:
On Tue, 06 Apr 2004 18:47:06 GMT, Andrew Thompson wrote:
On Tue, 06 Apr 2004 19:54:34 +0300, Stanimir Stamenkov wrote:
/Stanimir Stamenkov/:

Here are two cases regarding inline-level elements' line-height, padding
and background, which I doesn't understand:

Eh - no real CSSers around, really!? :-)


Apparently not in the 1hr 15mins
since you posted the question, no.


Ooops!! Try *3 days* 1hr 15mins.
Yeah, OK. Slight difference.


I looked at your code in a couple browsers (duplicating your results)
and read the CSS1 spec, but still have no answer for you. But I'm not
a CSS expert . . . yet.

--
lkseitz (Lee K. Seitz) .at. hiwaay @dot@ net
"This is the world we live in / And these are the hands we're given
Use them and let's start trying / To make it a place worth living in"
-- Genesis, "Land of Confusion"
Jul 20 '05 #5
/Lee K. Seitz/:
I looked at your code in a couple browsers (duplicating your results)
and read the CSS1 spec, but still have no answer for you. But I'm not
a CSS expert . . . yet.


Thank you, for looking at it, Lee.

I'm puzzled with these two related issues since long time but now
I've decided to ask the experts... it is that I'm still waiting for
one to come up. :-)

--
Stanimir
Jul 20 '05 #6
Stanimir Stamenkov <s7****@netscape.net> wrote:
Here are two cases regarding inline-level elements' line-height,
padding and background, which I doesn't understand:
The short answer is that the relationship between element boxes and
line boxes is not always obvious.

line-height determines the spacing between the baselines of adjacent
line boxes. It does not determine the height of any element boxes that
happen to lie within those line boxes.

This last point is not clear in CSS 2 where the text refers to "height
of each box generated by the element". CSS 2.1 clarifies this by
saying "height that is used in the calculation of the line box
height".
- section 10.8.1
<div style="background: black; color: white; line-height: 1.5">
<span>Abc</span>
<span style="background: white; color: black; line-height:
3">Abc</span>
<span>Abc</span>
</div>

Why doesn't the middle SPAN element have white background area tall
as 3em, but has white only behind the letters?
Any line boxes within this div are (font-size * 1.5) high except for
the line box that contains the middle span which is (font-size * 3)
high.

The span elements have a height determined by font-size alone.
<div style="background: black; color: white; line-height: 1.5;
font-size: 3em">
<span>Abc</span>
<span style="background: green; color: black; padding:
0.25em">Abc</span>
<span>Abc</span>
</div>

Why in the above example the green background area crosses the top
and bottom edges of the black background area?


Any line boxes within this div are (font-size * 1.5) high. The height
of the div is the sum of the heights of all the line boxes it
contains.

The span element has a height determined by font-size, and then there
is padding in addition to that height.

As the padding does not affect the font size, it does not affect the
line-height, and thus does not affect the height of the div.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #7
/Steve Pugh/:
The span elements have a height determined by font-size alone.
O.k. I've observed it prior asking, already. Just I hadn't found
clear explanation in the spec, before. But the next part:
Stanimir Stamenkov <s7****@netscape.net> wrote:
<div style="background: black; color: white; line-height: 1.5;
font-size: 3em">
<span>Abc</span>
<span style="background: green; color: black; padding:
0.25em">Abc</span>
<span>Abc</span>
</div>

Why in the above example the green background area crosses the top
and bottom edges of the black background area?
Any line boxes within this div are (font-size * 1.5) high. The height
of the div is the sum of the heights of all the line boxes it
contains.


Yes, that's fine. It is clear - the height of the DIV is (1.5 *
font-size)
The span element has a height determined by font-size, and then there
is padding in addition to that height.
So the SPAN element gets height of (font-size + (0.25 + 0.25) *
font-size) which is equivalent to (1.5 * font-size).
As the padding does not affect the font size, it does not affect the
line-height, and thus does not affect the height of the div.


The thing about the padding of an inline-level element doesn't
affect the line height is probably another unclear issue, but
nevertheless your answer doesn't reveal why:

(1.5 * font-size) - the DIV height

is not equal to (doesn't produce equal height background areas)

(1.5 * font-size) - the SPAN height

where the 'font-size' is same in the both expressions... ?

--
Stanimir
Jul 20 '05 #8
Stanimir Stamenkov <s7****@netscape.net> wrote:
/Steve Pugh/:
The span elements have a height determined by font-size alone.


O.k. I've observed it prior asking, already. Just I hadn't found
clear explanation in the spec, before. But the next part:
Stanimir Stamenkov <s7****@netscape.net> wrote:
<div style="background: black; color: white; line-height: 1.5;
font-size: 3em">
<span>Abc</span>
<span style="background: green; color: black; padding:
0.25em">Abc</span>
<span>Abc</span>
</div>

Why in the above example the green background area crosses the top
and bottom edges of the black background area?


Any line boxes within this div are (font-size * 1.5) high. The height
of the div is the sum of the heights of all the line boxes it
contains.


Yes, that's fine. It is clear - the height of the DIV is (1.5 *
font-size)
The span element has a height determined by font-size, and then there
is padding in addition to that height.


So the SPAN element gets height of (font-size + (0.25 + 0.25) *
font-size) which is equivalent to (1.5 * font-size).


No. The span element gets height of font-size. Padding does not
contribute to height.

But padding does use background-color, so the height of the
background-colored region is indeed (font-size + (font-size * (0.25 +
0.25)))
As the padding does not affect the font size, it does not affect the
line-height, and thus does not affect the height of the div.


The thing about the padding of an inline-level element doesn't
affect the line height is probably another unclear issue, but
nevertheless your answer doesn't reveal why:

(1.5 * font-size) - the DIV height

is not equal to (doesn't produce equal height background areas)

(1.5 * font-size) - the SPAN height

where the 'font-size' is same in the both expressions... ?


The height of the span is the same as the height of the div. But,
unless you are using the broken IE box model, padding goes outside of
height, and background colour affects padding as well as the content
area.

As the spec says:
"Although margins, borders, and padding of non-replaced elements do
not enter into the line box calculation, they are still rendered
around inline boxes. This means that 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. User agents should render the boxes in document
order. This will cause the borders on subsequent lines to paint over
the borders and text of previous lines."

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #9
>>>> <div style="background: black; color: white; line-height: 1.5;
font-size: 3em">
<span>Abc</span>
<span style="background: green; color: black; padding:
0.25em">Abc</span>
<span>Abc</span>
</div>

Why in the above example the green background area crosses the top
and bottom edges of the black background area?

/Steve Pugh/:
No. The span element gets height of font-size. Padding does not
contribute to height.

But padding does use background-color, so the height of the
background-colored region is indeed (font-size + (font-size * (0.25 +
0.25)))
Sorry, my bad. I've meant exactly:

The SPAN element gets background area tall as (1.5 * font-size).
Stanimir Stamenkov <s7****@netscape.net> wrote:
why:

(1.5 * font-size) - the DIV height

is not equal to (doesn't produce equal height background areas)

(1.5 * font-size) - the SPAN height

where the 'font-size' is same in the both expressions... ?
The height of the span is the same as the height of the div. But,
unless you are using the broken IE box model, padding goes outside of
height, and background colour affects padding as well as the content
area.


To "normalize" things:

The DIV background area (if there's no wrapping) is tall as the
line-height which is (1.5 * font-size) and the height of the SPAN is
(1 * font-size), but like you wrote and cite the spec below, it
should get background area tall as (height + padding-top +
padding-bottom) which again is (1.5 * font-size).

So, once again: Why the SPAN background area gets rendered taller
(just a little bit but still taller) than the DIV background area?
As the spec says:
"Although margins, borders, and padding of non-replaced elements do
not enter into the line box calculation, they are still rendered
around inline boxes. This means that 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. User agents should render the boxes in document
order. This will cause the borders on subsequent lines to paint over
the borders and text of previous lines."


--
Stanimir
Jul 20 '05 #10
Stanimir Stamenkov <s7****@netscape.net> wrote:
> <div style="background: black; color: white; line-height: 1.5;
> font-size: 3em">
> <span>Abc</span>
> <span style="background: green; color: black; padding:
> 0.25em">Abc</span>
> <span>Abc</span>
> </div>
>
> Why in the above example the green background area crosses the top
> and bottom edges of the black background area?
/Steve Pugh/:
No. The span element gets height of font-size. Padding does not
contribute to height.

But padding does use background-color, so the height of the
background-colored region is indeed (font-size + (font-size * (0.25 +
0.25)))
Sorry, my bad. I've meant exactly:

The SPAN element gets background area tall as (1.5 * font-size).


The span element is (1.5 * font-size) tall.

The region covered by the green background is
(height of span element) + 0.25 + 0.25 tall.
Stanimir Stamenkov <s7****@netscape.net> wrote:
why:

(1.5 * font-size) - the DIV height

is not equal to (doesn't produce equal height background areas)

(1.5 * font-size) - the SPAN height

where the 'font-size' is same in the both expressions... ?


The height of the span is the same as the height of the div. But,
unless you are using the broken IE box model, padding goes outside of
height, and background colour affects padding as well as the content
area.


To "normalize" things:

The DIV background area (if there's no wrapping) is tall as the
line-height which is (1.5 * font-size) and the height of the SPAN is
(1 * font-size),


No, it's (X * font-size). The height of inline elements is _based_on_
the font-size but isn't automatically the _same_as_ the font-size.
Sorry if this wasn't clear before.
but like you wrote and cite the spec below, it
should get background area tall as (height + padding-top +
padding-bottom)
Yes...
which again is (1.5 * font-size).
No. ((X + 0.5) * font-size).
So, once again: Why the SPAN background area gets rendered taller
(just a little bit but still taller) than the DIV background area?


Because, (X + 0.5) > 1.5

I have just noticed that the green area isn't tall enough.

In Mozilla (with a default 16px font size) it's only 79px tall. The
black area is 72px which is exactly what we'd expect (1.5 * 16 * 3).

It seems that the green area is being calculated as default
line-height (approx 1.15 * font-size) + padding rather than as
inherited line-height + padding.

This is allowable under the CSS2.1 spec which says that for inline
elements "The height of the content area should be based on the font,
but this specification does not specify how."

i.e. X in my statements above is taken as the default line-height
value; as opposed to either the inherited line-height value as one
might at first think, or 1 as I implied in my earlier posts.

IE6, in standards mode but not quirks mode, makes the green area the
same height as the black area. This may be a bug but is allowable unde
CSS2 but not CSS2.1 (the text "However, in this case, some user agents
may use the line box to "clip" the border and padding areas (i.e., not
render them)." has been removed from CSS2.1).

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #11
/Steve Pugh/:
No, it's (X * font-size). The height of inline elements is _based_on_
the font-size but isn't automatically the _same_as_ the font-size.
Sorry if this wasn't clear before.

[...]

It seems that the green area is being calculated as default
line-height (approx 1.15 * font-size) + padding rather than as
inherited line-height + padding.
O.k. This time I accept the explanation, given the CSS 2.1 spec
referrence below. :-)
This is allowable under the CSS2.1 spec which says that for inline
elements "The height of the content area should be based on the font,
but this specification does not specify how."

i.e. X in my statements above is taken as the default line-height
value; as opposed to either the inherited line-height value as one
might at first think, or 1 as I implied in my earlier posts.

IE6, in standards mode but not quirks mode, makes the green area the
same height as the black area. This may be a bug but is allowable unde
CSS2 but not CSS2.1 (the text "However, in this case, some user agents
may use the line box to "clip" the border and padding areas (i.e., not
render them)." has been removed from CSS2.1).


My tests showed IE6 (in both: standards and quirks mode) renders the
height of inline elements as (line-height: normal) but seems Mozilla
has some rounding bug (or just uses another unknown X):

<div style="background: black; color: white; font-size: 9em">
<span>Abc</span>
<span style="background: green; color: black">Abc</span>
<span>Abc</span>
</div>

--
Stanimir
Jul 20 '05 #12
/Stanimir Stamenkov/:
/Steve Pugh/:
[...much helpful comments...]


O.k. This time I accept the explanation, given the CSS 2.1 spec
referrence below. :-)


I forgot add: Thank you very much - for your help and patience.

--
Stanimir
Jul 20 '05 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

13
6529
by: A | last post by:
Hi, I'm having problems completing a project in C++. I have been using inline functions in some of my header files. I have only done so for simple functions that only have 1 statement (eg....
14
2742
by: Chris Mantoulidis | last post by:
I am not clear with the use of the keyword inline... I believe you add it do a function when you implement the function inside the header file where the class is stored... But is that all? What...
47
3800
by: Richard Hayden | last post by:
Hi, I have the following code: /******************************** file1.c #include <iostream> extern void dummy(); inline int testfunc() {
21
746
by: Rubén Campos | last post by:
I haven't found any previous message related to what I'm going to ask here, but accept my anticipated excuses if I'm wrong. I want to ask about the real usefulness of the 'inline' keyword. I've...
20
3107
by: Grumble | last post by:
Hello everyone, As far as I understand, the 'inline' keyword is a hint for the compiler to consider the function in question as a candidate for inlining, yes? What happens when a function with...
7
2849
by: Srini | last post by:
Hello, Rules for inline functions say that they have to be defined in the same compilation unit as their declarations. For class member functions this means that the inline member functions must...
9
2884
by: chinu | last post by:
hi all, i did a small experiment to grasp the advantages of declaring a function as inline. inline int fun1(); int main(){ unsigned int start=0,end=0; asm("rdtsc\n\t"
5
1909
by: Barry | last post by:
Hi, group First, I write same cases I've already known, I don't concern that specific compiler really do inline or not. Please check them if they are right, and add the cases I miss 1. //...
2
1547
by: Barry | last post by:
Hi, group First, I write same cases I've already known, I don't concern that specific compiler really do inline or not. Please check them if they are right, and add the cases I miss 1. //...
9
2110
by: Martin Wells | last post by:
Is there anything like __inline_is_supported to indicate whether a certain C compiler supports inline? I'm writing my code as fully portable C89, but I want to use inline. Martin
0
7242
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
7138
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
7353
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
7418
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
1
7075
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
3222
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The...
0
3212
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
781
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
446
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.