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 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
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
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
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"
/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
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/>
/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
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/>
>>>> <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
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/>
/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
/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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
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....
|
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...
|
by: Richard Hayden |
last post by:
Hi,
I have the following code:
/******************************** file1.c
#include <iostream>
extern void dummy();
inline int testfunc() {
|
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...
|
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...
| |
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...
|
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"
|
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.
//...
|
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.
//...
|
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
|
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,...
| |
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...
|
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,...
|
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...
|
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...
|
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...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
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...
| | |