473,224 Members | 1,604 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,224 software developers and data experts.

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 6694
/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
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
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
by: Richard Hayden | last post by:
Hi, I have the following code: /******************************** file1.c #include <iostream> extern void dummy(); inline int testfunc() {
21
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
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
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
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
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
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
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
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: jianzs | last post by:
Introduction Cloud-native applications are conventionally identified as those designed and nurtured on cloud infrastructure. Such applications, rooted in cloud technologies, skillfully benefit from...
0
by: mar23 | last post by:
Here's the situation. I have a form called frmDiceInventory with subform called subfrmDice. The subform's control source is linked to a query called qryDiceInventory. I've been trying to pick up the...
2
by: jimatqsi | last post by:
The boss wants the word "CONFIDENTIAL" overlaying certain reports. He wants it large, slanted across the page, on every page, very light gray, outlined letters, not block letters. I thought Word Art...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: stefan129 | last post by:
Hey forum members, I'm exploring options for SSL certificates for multiple domains. Has anyone had experience with multi-domain SSL certificates? Any recommendations on reliable providers or specific...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....

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.