Hello,
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title></title>
<style type="text/css">
body {background-color: white; color: black;}
#parent_block {background-color: red; width: 100%;}
#nested_child_b lock {margin: 150px 0px; background-color: green; color:
white;}
</style>
</head>
<body>
<div id="parent_bloc k"><p id="nested_chil d_block">foo</p></div>
2 questions regarding the above code.
1- Why Firefox 2 and Opera 9 do not render large red area above and
below the green child block? ... like MSIE 7 does
2- If I remove width: 100%, then MSIE 7 does not show the large red area
above and below the green child block. Why is that?
What am I missing?
Thank you
Gérard
--
remove blah to email me 11  2204 
"Gérard Talbot" <ne***********@ gtalbot.orgwrot e in message
news:12******** *****@corp.supe rnews.com...
Hello,
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title></title>
<style type="text/css">
body {background-color: white; color: black;}
#parent_block {background-color: red; width: 100%;}
#nested_child_b lock {margin: 150px 0px; background-color: green; color:
white;}
</style>
</head>
<body>
<div id="parent_bloc k"><p id="nested_chil d_block">foo</p></div>
2 questions regarding the above code.
1- Why Firefox 2 and Opera 9 do not render large red area above and
below the green child block? ... like MSIE 7 does
2- If I remove width: 100%, then MSIE 7 does not show the large red area
above and below the green child block. Why is that?
What am I missing?
Thank you
Gérard
See "8.3.1 Collapsing margins" in the w3.org css2 specs http://www.w3.org/TR/CSS21/box.html#collapsing-margins
"In this specification, the expression collapsing margins means that
adjoining margins (no non-empty content, padding or border areas or
clearance separate them) of two or more boxes (which may be next to one
another or nested) combine to form a single margin."
A better explanation: http://www.complexspiral.com/publica...psing-margins/
Rich
On 2006-10-30, Gérard Talbot <ne***********@ gtalbot.orgwrot e:
Hello,
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title></title>
<style type="text/css">
body {background-color: white; color: black;}
#parent_block {background-color: red; width: 100%;}
#nested_child_b lock {margin: 150px 0px; background-color: green; color:
white;}
</style>
</head>
<body>
<div id="parent_bloc k"><p id="nested_chil d_block">foo</p></div>
2 questions regarding the above code.
1- Why Firefox 2 and Opera 9 do not render large red area above and
below the green child block? ... like MSIE 7 does
This is because the child block's top and bottom margins should collapse
with those of the parent block, as rh said. MSIE 7 is failing to do
this.
2- If I remove width: 100%, then MSIE 7 does not show the large red area
above and below the green child block. Why is that?
The width: 100% is, according to the CSS specification, meaningless
here. The parent block's computed width should be 100% the width of its
container (in this case the viewport) anyway. So I think you're looking
at another MSIE 7 bug or non-conformance.
rh a écrit :
"Gérard Talbot" <ne***********@ gtalbot.orgwrot e in message
news:12******** *****@corp.supe rnews.com...
>Hello,
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title></title>
<style type="text/css">
body {background-color: white; color: black;}
#parent_bloc k {background-color: red; width: 100%;}
#nested_child_ block {margin: 150px 0px; background-color: green; color:
white;}
</style>
</head>
<body>
<div id="parent_bloc k"><p id="nested_chil d_block">foo</p></div>
2 questions regarding the above code.
1- Why Firefox 2 and Opera 9 do not render large red area above and
below the green child block? ... like MSIE 7 does
2- If I remove width: 100%, then MSIE 7 does not show the large red area
above and below the green child block. Why is that?
What am I missing?
Thank you
Gérard
See "8.3.1 Collapsing margins" in the w3.org css2 specs
http://www.w3.org/TR/CSS21/box.html#collapsing-margins
"In this specification, the expression collapsing margins means that
adjoining margins (no non-empty content, padding or border areas or
clearance separate them) of two or more boxes (which may be next to one
another or nested) combine to form a single margin."
A better explanation:
http://www.complexspiral.com/publica...psing-margins/
Rich
Rich, I still do not understand why Firefox 2 and Opera 9 render the
margin area as white and not red. In the following testcase:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title>Why the margin area is not red?</title>
<style type="text/css">
body {background-color: white; color: black; margin: 0px;}
#parent_block {background-color: red; width: 100%; margin: 0px;}
#nested_child_b lock {margin: 150px 0px; background-color: green; color:
white;}
</style>
<div id="parent_bloc k"><p id="nested_chil d_block">foo</p></div>
there is no collapsing of margin involved. MSIE 7 (final release)
renders the margin area as red, not white. Firefox 2.0 and Opera 9.1
render the margin area as white, not red. I wish to understand why.
Thank you for your time,
Gérard
--
remove blah to email me
On 2006-11-01, Gérard Talbot <ne***********@ gtalbot.orgwrot e:
[snip]
>><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title></title>
<style type="text/css">
body {background-color: white; color: black;}
#parent_blo ck {background-color: red; width: 100%;}
#nested_child _block {margin: 150px 0px; background-color: green; color:
white;}
</style>
</head>
<body>
<div id="parent_bloc k"><p id="nested_chil d_block">foo</p></div>
2 questions regarding the above code.
1- Why Firefox 2 and Opera 9 do not render large red area above and
below the green child block? ... like MSIE 7 does
[snip]
>See "8.3.1 Collapsing margins" in the w3.org css2 specs
http://www.w3.org/TR/CSS21/box.html#collapsing-margins
"In this specification, the expression collapsing margins means that
adjoining margins (no non-empty content, padding or border areas or
clearance separate them) of two or more boxes (which may be next to one
another or nested) combine to form a single margin."
A better explanation:
http://www.complexspiral.com/publica...psing-margins/
Rich
Rich, I still do not understand why Firefox 2 and Opera 9 render the
margin area as white and not red. In the following testcase:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title>Why the margin area is not red?</title>
<style type="text/css">
body {background-color: white; color: black; margin: 0px;}
#parent_block {background-color: red; width: 100%; margin: 0px;}
#nested_child_b lock {margin: 150px 0px; background-color: green; color:
white;}
</style>
<div id="parent_bloc k"><p id="nested_chil d_block">foo</p></div>
there is no collapsing of margin involved. MSIE 7 (final release)
renders the margin area as red, not white. Firefox 2.0 and Opera 9.1
render the margin area as white, not red. I wish to understand why.
I'm not Rich, but I'll have a go at explaining.
There _is_ collapsing of margin involved (or should be-- MSIE 7 is wrong
on this one). The nested_child_bl ock has top and bottom margins of 150px
and the parent block has top and bottom margins of 0px.
A box's margins can collapse with those of its children. If a box has a
top margin, and the first block box nested inside that box also has a
top margin, and the outer box has no border or padding, those two top
margins count as "adjacent" and collapse together.
And that's just what the situation is here-- the parent_block's top
margin of 0px is adacent with its child's top margin of 150px. The two
collapse to a resultant margin of 150px which goes above parent_block
and serves as the top margin area for both boxes.
An easier way perhaps to understand this is to think about what a margin
is. A margin is a requirement for space between the edge of a box and
some kind of boundary. A box's margin _starts_ outside its border, which
is outside its padding, which is outside its content area. If the box
has no border, then the margin effectively starts at the outside of the
padding; and if it has no padding, then the margin effectively starts at
the outside of the content area. But a margin can only _end_ at an
actual padding edge or border edge of some other box or at the edge of
the viewport itself.
The nested_child_bl ock must have 150px of fresh air above it. That is
what the styles ask for. But what is at the other end of that 150px? It
has to be a padding edge, border edge or the edge of the viewport. The
top of parent_block is not a good enough boundary because parent_block
has no padding or border. That is why you don't (or shouldn't) get
parent_block growing in height to leave space inside itself for the
nested_child_bl ock's top margin.
Give parent_block top padding of 1px or a top border and you will see
the margin appearing below it, inside parent_block, and therefore with a
red background.
What happens if you give parent_block a top margin (but no padding or
border) of 10px in IE? Do you get another 10px above it? If so, you've
got 160px altogether of margin between the top of nested_child_bl ock and
the viewport edge (the nearest margin-end boundary). That's too big, the
styles only ask for 150px, which is why we can say IE is wrong. That's
why margins collapse, to ensure that the gaps between where margins
start and where they are allowed to end (padding, border or viewport
edges only) are never bigger than the maximums required by what the
styles have asked for.
Ben C a écrit :
>>See "8.3.1 Collapsing margins" in the w3.org css2 specs
http://www.w3.org/TR/CSS21/box.html#collapsing-margins
"In this specification, the expression collapsing margins means that
adjoining margins (no non-empty content, padding or border areas or
clearance separate them) of two or more boxes (which may be next to one
another or nested) combine to form a single margin."
A better explanation:
http://www.complexspiral.com/publica...psing-margins/
Rich
Rich, I still do not understand why Firefox 2 and Opera 9 render the
margin area as white and not red. In the following testcase:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title>Why the margin area is not red?</title>
<style type="text/css">
body {background-color: white; color: black; margin: 0px;}
#parent_bloc k {background-color: red; width: 100%; margin: 0px;}
#nested_child_ block {margin: 150px 0px; background-color: green; color:
white;}
</style>
<div id="parent_bloc k"><p id="nested_chil d_block">foo</p></div>
there is no collapsing of margin involved. MSIE 7 (final release)
renders the margin area as red, not white. Firefox 2.0 and Opera 9.1
render the margin area as white, not red. I wish to understand why.
I'm not Rich, but I'll have a go at explaining.
There _is_ collapsing of margin involved (or should be-- MSIE 7 is wrong
on this one). The nested_child_bl ock has top and bottom margins of 150px
and the parent block has top and bottom margins of 0px.
A box's margins can collapse with those of its children. If a box has a
top margin, and the first block box nested inside that box also has a
top margin, and the outer box has no border or padding, those two top
margins count as "adjacent" and collapse together.
So far, I understand what you say and what the spec says.
And that's just what the situation is here-- the parent_block's top
margin of 0px is adacent with its child's top margin of 150px. The two
collapse to a resultant margin of 150px which goes above parent_block
"which goes above parent_block": where do you see/read this in CSS 2.1?
I've read and read again the latest spec: http://www.w3.org/TR/2006/WD-CSS21-2...apsing-margins
Where do you read that the resultant margin takes its background color
from closest containing box (body in my example) within the containing
hierarchy?
In other words, how/where does the current spec says that MSIE7 renders
the above demo wrong and Firefox 2 and Opera 9.x render it correctly:
the only difference in the rendering is the background-color of
adjoining margins which is 150px.
body {background-color: white; color: black; margin: 0px;}
#parent_block {background-color: red; width: 100%; margin: 0px;}
#nested_child_b lock {margin: 150px 0px; background-color: green; color:
white;}
and serves as the top margin area for both boxes.
Gérard
--
remove blah to email me
Ben C wrote :
On 2006-11-01, G�rard Talbot <ne***********@ gtalbot.orgwrot e:
[snip]
>>><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title></title>
<style type="text/css">
body {background-color: white; color: black;}
#parent_bloc k {background-color: red; width: 100%;}
#nested_chil d_block {margin: 150px 0px; background-color: green; color:
white;}
</style>
</head>
<body>
<div id="parent_bloc k"><p id="nested_chil d_block">foo</p></div>
2 questions regarding the above code.
1- Why Firefox 2 and Opera 9 do not render large red area above and
below the green child block? ... like MSIE 7 does
[snip]
>>See "8.3.1 Collapsing margins" in the w3.org css2 specs
http://www.w3.org/TR/CSS21/box.html#collapsing-margins
"In this specification, the expression collapsing margins means that
adjoining margins (no non-empty content, padding or border areas or
clearance separate them) of two or more boxes (which may be next to one
another or nested) combine to form a single margin."
A better explanation:
http://www.complexspiral.com/publica...psing-margins/
Rich
Rich, I still do not understand why Firefox 2 and Opera 9 render the
margin area as white and not red. In the following testcase:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title>Why the margin area is not red?</title>
<style type="text/css">
body {background-color: white; color: black; margin: 0px;}
#parent_bloc k {background-color: red; width: 100%; margin: 0px;}
#nested_child_ block {margin: 150px 0px; background-color: green; color:
white;}
</style>
<div id="parent_bloc k"><p id="nested_chil d_block">foo</p></div>
there is no collapsing of margin involved. MSIE 7 (final release)
renders the margin area as red, not white. Firefox 2.0 and Opera 9.1
render the margin area as white, not red. I wish to understand why.
I'm not Rich, but I'll have a go at explaining.
There _is_ collapsing of margin involved (or should be-- MSIE 7 is wrong
on this one). The nested_child_bl ock has top and bottom margins of 150px
and the parent block has top and bottom margins of 0px.
A box's margins can collapse with those of its children. If a box has a
top margin, and the first block box nested inside that box also has a
top margin, and the outer box has no border or padding, those two top
margins count as "adjacent" and collapse together.
And that's just what the situation is here-- the parent_block's top
margin of 0px is adacent with its child's top margin of 150px. The two
collapse to a resultant margin of 150px which goes above parent_block
and serves as the top margin area for both boxes.
An easier way perhaps to understand this is to think about what a margin
is. A margin is a requirement for space between the edge of a box and
some kind of boundary. A box's margin _starts_ outside its border, which
is outside its padding, which is outside its content area. If the box
has no border, then the margin effectively starts at the outside of the
padding; and if it has no padding, then the margin effectively starts at
the outside of the content area. But a margin can only _end_ at an
actual padding edge or border edge of some other box or at the edge of
the viewport itself.
In this case, it's the closest containing block which is the body element.
I understand what you're saying... Your explanation is rational...but
the spec is not **__explicit__* *, thoroughly explicit on this precise issue.
>
The nested_child_bl ock must have 150px of fresh air above it. That is
what the styles ask for. But what is at the other end of that 150px? It
has to be a padding edge, border edge or the edge of the viewport. The
top of parent_block is not a good enough boundary because parent_block
has no padding or border. That is why you don't (or shouldn't) get
parent_block growing in height to leave space inside itself for the
nested_child_bl ock's top margin.
Give parent_block top padding of 1px or a top border and you will see
the margin appearing below it, inside parent_block, and therefore with a
red background.
What happens if you give parent_block a top margin (but no padding or
border) of 10px in IE? Do you get another 10px above it? If so, you've
got 160px altogether of margin between the top of nested_child_bl ock and
the viewport edge (the nearest margin-end boundary).
That is another issue, a separate, distinct issue. I can see that MSIE
6+ does not collapse margin when it should. What the CSS 2.1 spec does
not say (well.. I can't find where exactly it would say that) is that
the resultant adjoining margin uses (or should use) the containing block
to position the parent_block and should use the background-color of
containing block of parent_block in my example.
That's too big, the
styles only ask for 150px, which is why we can say IE is wrong.
It is wrong. As soon as August 22nd, we knew this bug had not been fixed
and would not be fixed in IE 7 final release
"
- Float model is still incorrect in many cases
- Basic CSS positioning is still incorrect in many cases
- z-index is still incorrect
- inheritance is still broken in almost all cases
- margin-collapsing is still incorrect
"
by Tino Zijdel
IE 7 Blog
Details on our CSS changes for IE7 http://blogs.msdn.com/ie/archive/200...30.aspx#713072
I'll read again your post and the spec some time later...
Gérard
--
remove blah to email me
"Gérard Talbot" <ne***********@ gtalbot.orgwrot e in message
news:12******** *****@corp.supe rnews.com...
Ben C a écrit :
<snip>
First, remove the width:100% to see MSIE display correctly.
Must be another *feature* of MSIE to display as you expect when the width
is set to 100%
Where do you read that the resultant margin takes its background color
from closest containing box (body in my example) within the containing
hierarchy?
The margin has no background color. A margin is the space around an
element. Try putting a border around your example divs. ie, border: 2px
solid black;
I don't think you understand how margins work. I'll give a simple
explaination.
A margin of 150px on a div simply means that you do not want any content
(in the same stacking context) to come within 150px of that div. The margin
itsself has no properties such as backgound color (there's no margin-color,
or margin-border), it's just space. If there is a background-color or
background-image "behind" the div, it will show through the margin.
In this case, your parent div has no content, no borders, no padding. In
other words there is nothing for the margin in the child div to "keep away"
so the border of parent div does not expand to "keep away" from the child
div. That's where the margins collapse. The parent div is essentially the
same size as the child div which is why you can't see the background of the
parent div. The child div still wants to maintain a 150px margin so it
applies it to the next available content, in this case it's the body so you
get the body's background color "showing through" the margin of the child
div.
Try putting a border on, or some padding in, the parent div. The margins on
the child div will then have something to "keep away". If you just put a
margin on the parent div (with no border, padding, or content), it won't
work, the margins will "collapse" and the largest margin will apply.
Read the links I posted earlier (again) for other ways margins can collapse
(see the paragraph examples)
Rich
On 2006-11-01, Gérard Talbot <ne***********@ gtalbot.orgwrot e:
Ben C a écrit :
[snip]
>><title>Why the margin area is not red?</title>
<style type="text/css">
body {background-color: white; color: black; margin: 0px;}
#parent_blo ck {background-color: red; width: 100%; margin: 0px;}
#nested_child _block {margin: 150px 0px; background-color: green; color:
white;}
</style>
<div id="parent_bloc k"><p id="nested_chil d_block">foo</p></div>
there is no collapsing of margin involved. MSIE 7 (final release)
renders the margin area as red, not white. Firefox 2.0 and Opera 9.1
render the margin area as white, not red. I wish to understand why.
[snip]
So far, I understand what you say and what the spec says.
>And that's just what the situation is here-- the parent_block's top
margin of 0px is adacent with its child's top margin of 150px. The two
collapse to a resultant margin of 150px which goes above parent_block
"which goes above parent_block": where do you see/read this in CSS 2.1?
The spec tells us that the computed top margin on the parent_block is
the result of collapsing 150 and 0, which is 150. Therefore parent_block
has a top margin of 150.
It's true noone asked explicitly for 150px above the top edge of
parent_block, and leaving parent_block with a computed top margin of 0px
still gives nested_child_bl ock its requested top margin of 150px and no
larger. So this is a corner case, where we are following the letter
rather than the spirit of the spec.
As discussed elsewhere on the other hand if parent_block's top margin is
non-zero then it is essential that its computed margin is the result of
collapsing with its child's top margin, or we have too much space above
the child.
Where do you read that the resultant margin takes its background color
from closest containing box (body in my example) within the containing
hierarchy?
The margin of a box is outside the area that's painted with its
background colour. So parent_block's top margin area must not be red in
this example, any more than nested_child_bl ock's margin area should be
green.
This is section 8.1 of the CSS 2.1 spec, and there's a useful diagram.
You probably knew all that anyway; the less obvious thing here I think
is that parent_block itself has a computed top margin of 150px.
On 2006-11-02, Gérard Talbot <ne***********@ gtalbot.orgwrot e:
Ben C wrote :
[snip]
>An easier way perhaps to understand this is to think about what a margin
is. A margin is a requirement for space between the edge of a box and
some kind of boundary. A box's margin _starts_ outside its border, which
is outside its padding, which is outside its content area. If the box
has no border, then the margin effectively starts at the outside of the
padding; and if it has no padding, then the margin effectively starts at
the outside of the content area. But a margin can only _end_ at an
actual padding edge or border edge of some other box or at the edge of
the viewport itself.
In this case, it's the closest containing block which is the body element.
I understand what you're saying... Your explanation is rational...but
the spec is not **__explicit__* *, thoroughly explicit on this precise issue.
It is thoroughly implicit on this precise issue.
[snip]
>What happens if you give parent_block a top margin (but no padding or
border) of 10px in IE? Do you get another 10px above it? If so, you've
got 160px altogether of margin between the top of nested_child_bl ock and
the viewport edge (the nearest margin-end boundary).
That is another issue, a separate, distinct issue. I can see that MSIE
6+ does not collapse margin when it should. What the CSS 2.1 spec does
not say (well.. I can't find where exactly it would say that) is that
the resultant adjoining margin uses (or should use) the containing block
to position the parent_block and should use the background-color of
containing block of parent_block in my example.
That's too big, the
>styles only ask for 150px, which is why we can say IE is wrong.
It is wrong.
You're right that this is more wrong than in the case where the top
margin of parent_block is 0px. Because here we have the tangible error
that nested_child_bl ock's top margin is too big. In the 0px case, IE has
failed to set parent_block's top margin to collapse(150, 0), which the
spec implies it should, even if looking at the bigger picture, there's
no particularly good reason to.
As soon as August 22nd, we knew this bug had not been fixed
and would not be fixed in IE 7 final release
"
- Float model is still incorrect in many cases
- Basic CSS positioning is still incorrect in many cases
- z-index is still incorrect
- inheritance is still broken in almost all cases
- margin-collapsing is still incorrect
We're not the only ones having trouble understanding margin-collapsing
then :)
Actually I think it is one of the hardest parts of the spec.
Try the following example in Opera and FF. Opera leaves 20px above the
first block and 50px between them. Firefox and Konqueror leave 50px
above the first block and 20px between them. I believe FF and Konqueror
are following the implicit requirements of the spec, but the result is
somewhat counter-intuitive. Basically the first block gets a computed
top margin of 50px as a result of the bottom margin of the zero-height
nested block.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<style type="text/css">
div.test
{
border: 2px solid gray;
background-color: cornsilk;
width: 30px;
margin: 2px;
}
</style>
</head>
<body>
<div class="test">
<div style="backgrou nd-color: green;
margin: 20px 5px; height: 20px;">
<div style="backgrou nd-color: pink;
height: auto;
margin: 20px 5px 50px 5px;">
</div>
</div>
<div style="backgrou nd-color: green;
margin: 20px 5px;
height: 20px;">
</div>
</div>
</body>
</html> This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: lorelei |
last post by:
Hey all,
I have found two seperate HTML codes which claim to stop background
images from being tiled. Neither of them seem to be working. I'm
writing my codes in Textpad, and use Internet Explorer 6 for my
browser.
Below you will find the two codes I've found. Can anyone tell me why
the hell they're not working?! This is driving me insane... moreso!!!!
|
by: Chris Beall |
last post by:
I'm displaying an image that is also a link against a black background.
In Netscape 7.1, the current background color is displayed as a
horizontal bar below the image. This allows :hover effects that change
the background color to have a visible effect, as this bar changes
color. By default, it appears that the color is inherited from the body
color, i.e. with no link style applied, the bar is black, and invisible
against the background....
|
by: Nikolaos Giannopoulos |
last post by:
If I have simplified html (I have removed height, weight, alt, etc...
attributes to simplify the example) such as:
<div id="header">
<a href="blah.html"><img src="img/blah.jpg"></a>
</div>
and the following CSS rule to apply a background color to text links on
hover:
|
by: Stanimir Stamenkov |
last post by:
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>
|
by: Kevin Yu |
last post by:
When I declare on HTML page
<LINK href="mycss.css" type="text/css" rel=stylesheet />
....
<BODY class=myclass>
in mycss.css
BODY { FONT-WEIGHT: bold; FONT-SIZE: 12px; FONT-FAMILY: Arial, Geneva; background-image: url(images/back.jpg); }
| | |
by: day |
last post by:
I'm trying to use a non-scrolling background image within a div (the
non-scrolling part is a "nice-to-have" vs a "have to have"). The
style for that is:
<div style="height=400px;
background-image:url(bgrd-foo.jpg);
background-position: center top;
background-repeat:no-repeat;
background-attachment: fixed;">
|
by: dudelman |
last post by:
Hi Folks,
I have stumbled over this website
<http://www.westciv.com/style_master/academy/css_tutorial/index.html>
and I wonder how they manage to invert the colors of the fixed
background image when scrolling downward and the blue header moves
away. I do not find any directive of the header beckground which tells
to invert the underlying bg image.
Any hints?
|
by: Giggle Girl |
last post by:
Hi there,
I need to use a background image in a TR that does NOT restart
everytime it hits a TD. Can it be done?
Specifically, if you set a background image for an entier table, now
mater how many TRs and TDs you have, it will show the
complete/unfragmented image (as long as you don't over-ride it).
When I set a TR background image, every time I hit a TD it "re-seeds"
the image. I want to have a TR that shows an 800px image in it's
|
by: Rob |
last post by:
Hello,
I'm sure this has come up before. I have need for a collection of all
elements/objects in an HTML document that have any kind of an
attribute (HTML or CSS) that is making use of a URL to display an
image. document.images only seems to reference image tags. The
collection needs to include background images, input type = image,
image maps, css assigned background, etc. Honestly, I am probably not
aware of all the possibilities...
|
by: salmobytes |
last post by:
Making thumbnail images isn't all that hard, for the most
part. There is lots of shrink-wrapped code out there you
can download and/or munge from. But nothing I've yet
seen does the right thing with transparent background gifs.
If you (I) try to work with ImageCreateFromGif($this->path);
you end up with a black background.
Does anybody know how to make transparent background
gif thumbnails? Or maybe how to at least turn the background
|
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, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
| | |
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 effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
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, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
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 Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
| | |
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| |
