473,413 Members | 1,727 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,413 software developers and data experts.

the height property

Because of my experience posting various places over the last couple of
weeks: I'm expecting to be greated with hostility for asking about
concepts instead of "practical" things, since that has been my
experience for years and decades. Maybe I'm projecting hostility. I
don't know. How can I ask about theory and concepts without offending
people? I'll just continue asking and cross my fingers:

According to the 2.1 spec, regarding block-level non-replaced elements
in normal-flow with block-level children (e.g. a div element with
display: static and a "p" child element):

1. Does the height property have a meaning when specified on elements
that have the viewport as their containing block and that are not the
root element?

Say I have a div element containing a "p" element, with style like:

div {
height: 100%;
}

and it's containing block is the browser window (the viewport), does the
height property have a meaning?

In http://www.w3.org/TR/CSS21/visudet.h...eight-property in the
prose about percentage values it says:

"... If the height of the containing block is not specified explicitly
(i.e., it depends on content height), and this element is not absolutely
positioned, the value is interpreted like 'auto'."

Is the viewport treated as a block that has it's height explicitly
specified?

The next sentence is:

"A percentage height on the root element is relative to the viewport."

I gather that means, it makes sense to set a percentage height on the
root element at least. But, what about percentage heights on block-level
elements that are not the root element but that have the viewport as
their containing block (that are non-replaced and in normal flow, e.g. a
div element with display: relative or no display property set)?

I would assume that the viewport is treated as though it has it's height
explicitly set, except that in my testing with mozilla, setting height:
100% is not causing the box to extend from the top of the viewport to
the bottom, and there is qualified text later that makes me think that
the height property is ignored on non-replaced normal flow elements,
i.e. the third paragraph in 10.6.3.

2. Are the effective margins of the topmost and bottommost block-level
child boxes included in the height of a non-replaced block-level element
in normal flow when those margins are collapsed with some other margin?

http://www.w3.org/TR/CSS21/visudet.html#normal-block

"If it.." [the non-replaced block-level element in normal flow with
overflow computing to visible] "...has block-level children, the height
is the distance between the top border-edge of the topmost block-level
child box that doesn't have margins collapsed through it and the bottom
border-edge of the bottommost block-level child box that doesn't have
margins collapsed through it."

I don't understand the part that reads "...the topmost block-level child
box that doesn't have margins collapsed through it".

I think it might be saying that the height property is ignored on
non-replaced etc. etc. elements, that have block-level children, and
that the height is derived from the height of the children plus their
margins, taking into considering any margin collapsing, but I'm not sure
what to make of the bit about the collapsed margins.

Does it mean that, the height of the topmost block-level child box and
it's effective margins are ignored if it has a top-margin that is
collapsed with it's own topmost block-level child box? It can't be...
What does it mean?

3. Do margins have a meaning on the root element?

Regarding the sentence after the quote above, in:

http://www.w3.org/TR/CSS21/visudet.html#normal-block

"However, if the element has a non-zero top padding and/or top border,
or is the root element, then the content starts at the top margin edge
of the topmost child.

Is it correct to say: the viewport has 0 width margins (or margins have
no meaning on the viewport), margins in general increase above and below
the height of a block (unless they are negative), and that margins
specified on the root element are ignored? If not, what am I missing?

Jul 20 '05 #1
5 2887
Secret Guy <no****@nope.no> wrote:
According to the 2.1 spec, regarding block-level non-replaced elements
in normal-flow with block-level children (e.g. a div element with
display: static and a "p" child element):

1. Does the height property have a meaning when specified on elements
that have the viewport as their containing block and that are not the
root element?
The only such elements are those with position: absolute; or position:
fixed; All other elements will have at least one ancestor that can
serve as a containing block (i.e. the root element) between themselves
and the initial containing block (which is often taken to be the
viewport).
Say I have a div element containing a "p" element, with style like:

div {
height: 100%;
}

and it's containing block is the browser window (the viewport),
Why do you think the browser window the containing block?

"For other elements, if the element's position is 'relative' or
'static', the containing block is formed by the content edge of the
nearest block-level, table cell or inline-block ancestor box."
http://www.w3.org/TR/CSS21/visudet.html#x0

There is a <body> element, at least, around your <div>. Hence that is
the containing block, not the viewport.
does the height property have a meaning?

In http://www.w3.org/TR/CSS21/visudet.h...eight-property in the
prose about percentage values it says:

"... If the height of the containing block is not specified explicitly
(i.e., it depends on content height), and this element is not absolutely
positioned, the value is interpreted like 'auto'."
This applies to your <div>.
Is the viewport treated as a block that has it's height explicitly
specified?
Interesting question but irrelevant to this case.
The next sentence is:

"A percentage height on the root element is relative to the viewport."

I gather that means, it makes sense to set a percentage height on the
root element at least.
'Makes sense' is somewhat subjective. But there is a well defined
meaning for how such a setting will be calculated.
But, what about percentage heights on block-level
elements that are not the root element but that have the viewport as
their containing block (that are non-replaced and in normal flow, e.g. a
div element with display: relative or no display property set)?
But there are no such elements:
* The only elements that can have the initial containing block (which
may or may not be the viewport) as their containing block are the root
element and an element with position: absolute; .
* Elements with position: fixed; always take the viewport as their
containing block.
* Elements with position: relative; or position: fixed; take their
nearest block-level, table cell or inline-block ancestor element as
their containing block;
I would assume that the viewport is treated as though it has it's height
explicitly set, except that in my testing with mozilla, setting height:
100% is not causing the box to extend from the top of the viewport to
the bottom,
Do you also have heights set for your <html> and <body> elements?
There are ancestors of your <div> but do not by default have explicit
heights.
and there is qualified text later that makes me think that
the height property is ignored on non-replaced normal flow elements,
i.e. the third paragraph in 10.6.3.
I don't see anything that implies that.
2. Are the effective margins of the topmost and bottommost block-level
child boxes included in the height of a non-replaced block-level element
in normal flow when those margins are collapsed with some other margin?

http://www.w3.org/TR/CSS21/visudet.html#normal-block

"If it.." [the non-replaced block-level element in normal flow with
overflow computing to visible] "...has block-level children, the height
is the distance between the top border-edge of the topmost block-level
child box that doesn't have margins collapsed through it and the bottom
border-edge of the bottommost block-level child box that doesn't have
margins collapsed through it."

I don't understand the part that reads "...the topmost block-level child
box that doesn't have margins collapsed through it".
If the child boxes are empty and have no set height, padding or
borders then the margins for adjacent boxes can collapse as if the
empty child box wasn't there. Hence 'collapse through it'.
I think it might be saying that the height property is ignored on
non-replaced etc. etc. elements, that have block-level children, and
that the height is derived from the height of the children plus their
margins,
No.
taking into considering any margin collapsing, but I'm not sure
what to make of the bit about the collapsed margins.

Does it mean that, the height of the topmost block-level child box and
it's effective margins are ignored if it has a top-margin that is
collapsed with it's own topmost block-level child box? It can't be...
What does it mean?
In simplest terms it means that the height of the parent block
(assuming height: auto) is calculated after any collapsing of margins
has taken place. If the topmost child is empty then it's possible that
the margins of the second to top child will collapse through it and
hence the height of the parent will be calculated from the top of the
second child not the first.
3. Do margins have a meaning on the root element?

Regarding the sentence after the quote above, in:

http://www.w3.org/TR/CSS21/visudet.html#normal-block

"However, if the element has a non-zero top padding and/or top border,
or is the root element, then the content starts at the top margin edge
of the topmost child.
This is saying two things:
1. If the first child has non-zero border and padding then the height
of the parent starts form where these start (i.e. the inner edge of
the child's margins). Okay, no problems there.

2. If the parent itself is the root element then the height agains
starts from the inner edge of the first child's margins. Is this rule
being included for the sake of completeness or does it actually change
the display under some circumstances?
Is it correct to say: the viewport has 0 width margins (or margins have
no meaning on the viewport), margins in general increase above and below
the height of a block (unless they are negative), and that margins
specified on the root element are ignored? If not, what am I missing?


The viewport itself is not stylable via CSS. And as you correctly
point out the margins of the viewport would be rendered outside the
browser window and so have no meaning.

You seem to have jumped from the root element to the viewport. They
are not the same thing.

To bring this round to practical considerations (I know) there is a
problem in that browsers interpret the viewport, initial containing
block, root element, html element and body element in different ways.
If one browser, for example, takes the html element as the root
element and another has an anonymous root element, we have difficulty
is constructing test cases to see how the spec has been implemented.

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 #2
Steve Pugh wrote:
Secret Guy <no****@nope.no> wrote:
1. Does the height property have a meaning when specified on elements
that have the viewport as their containing block and that are not the
root element?
The only such elements are those with position: absolute; or position:
fixed; All other elements will have at least one ancestor that can
serve as a containing block (i.e. the root element) between themselves
and the initial containing block (which is often taken to be the
viewport).
Oh, that might clear up a lot of things for me. I was thinking that body
was inline. I also thought that body was considered the root element.

It's not that important for me I guess, but what if body and html had
display set to inline? Wouldn't that mean that some normal flow
block-level descendant could have the viewport as it's containing block?
And if so, would the height property on that element be treated like
auto (because the viewport is not considered to have height explicitly
set)?
I would assume that the viewport is treated as though it has it's height
explicitly set, except that in my testing with mozilla, setting height:
100% is not causing the box to extend from the top of the viewport to
the bottom,

Do you also have heights set for your <html> and <body> elements?
There are ancestors of your <div> but do not by default have explicit
heights.


No, I only had height set on body. It does what I expect now if I set
height on html as well. Thanks.
http://www.w3.org/TR/CSS21/visudet.html#normal-block

"However, if the element has a non-zero top padding and/or top border,
or is the root element, then the content starts at the top margin edge
of the topmost child.


I should point out that I was not sure about the part "...the content
starts at...". Because, I thought "the content" is what is inside the
content edge. I'm pretty sure after reading your explanation that it
means that the top margin of the topmost child is included in this case,
when determening the heights of the children.
This is saying two things:
1. If the first child has non-zero border and padding then the height
of the parent starts form where these start (i.e. the inner edge of
the child's margins). Okay, no problems there.
So, "the element" in "However, if the element...", is the first child? I
thought "the element" was the element who's height is being determined.

Isn't it: If the element who's height is being determined (the parent)
has non-zero top border or top padding then, because it's top-margin
will not collapse with the margin of it's topmost child, the height of
the children will be considered to include the top-margin of the topmost
child?
2. If the parent itself is the root element then the height agains
starts from the inner edge of the first child's margins. Is this rule
being included for the sake of completeness or does it actually change
the display under some circumstances?


Why the inner edge? Isn't it the margin edge of the first child? In
other words, is it saying that the height of the children of the root
element is considered to include the top margin of it's first child?

Can you help me with the other question I was asking, that is somewhat
related? How can I make a box that is visibly inset by some measure,
e.g. 5px from the viewport, on all sides, without specifying an absolute
height and width that requires me to know the height/width of the
browser window, and without using position: absolute?

For example, this is not the way, apparently:

[?xml version="1.0"?>
[!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
[html>
[head>
[title>One Box[/title>
[style type="text/css">
html {
background-color: yellow;
height: 100%;
}
body {
height: 100%;
margin: 5px;
background-color: green;
}
[/style>
[/head>
[body/>
[/html>
Jul 20 '05 #3
Secret Guy <no****@nope.no> wrote:
Steve Pugh wrote:
Secret Guy <no****@nope.no> wrote:
http://www.w3.org/TR/CSS21/visudet.html#normal-block

"However, if the element has a non-zero top padding and/or top border,
or is the root element, then the content starts at the top margin edge
of the topmost child.
This is saying two things:
1. If the first child has non-zero border and padding then the height
of the parent starts form where these start (i.e. the inner edge of
the child's margins). Okay, no problems there.


So, "the element" in "However, if the element...", is the first child? I
thought "the element" was the element who's height is being determined.


Ah sorry. I may have made a mistake here. Let me check the full
context in the spec...

.... whoops yes, my mistake.
Isn't it: If the element who's height is being determined (the parent)
has non-zero top border or top padding then, because it's top-margin
will not collapse with the margin of it's topmost child, the height of
the children will be considered to include the top-margin of the topmost
child?
Correct.

I think between what I said and what you worked out despite my mistake
we got everything straight?
Can you help me with the other question I was asking, that is somewhat
related? How can I make a box that is visibly inset by some measure,
e.g. 5px from the viewport, on all sides, without specifying an absolute
height and width that requires me to know the height/width of the
browser window, and without using position: absolute?

For example, this is not the way, apparently:
What's with the square brackets? If your newsreader is so broken as to
parse HTML in plain text news posts then you should fix your
newsreader not mangle your posts.
[?xml version="1.0"?>
[!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
[html>
[head>
[title>One Box[/title>
[style type="text/css">
html {
background-color: yellow;
height: 100%;
}
body {
height: 100%;
margin: 5px;
background-color: green;
}
[/style>
[/head>
[body/>
[/html>


Well you're making your body (100% + 10px + padding) high, so this
will be slightly taller than the viewport. As shown in Opera (which
has default padding on body) and Mozilla (which doesn't). The bottom
margin isn't visible via scrolling - presumably anything outside the
height of the body isn't considered important.

IE takes the background-color of the body and applies it to the space
created by the margins on the body. This is an error in this case
(applying body background properties to html is allowed only when html
itself doesn't have background properties set).

html { height: 100%; }
body { height: 100%;
margin: 0;
padding: 0;
background-color: green;
border: 5px solid yellow;
}
Gets a bit closer. Opera and Mozilla still make the page 100%+10px
high but the bottom border can be seen by scrolling. IE places the
scrollbar inside the border, which is annoying.

As you can see from http://www.sfsfw.net/ I introduced a redundent div
around the content and didn't bother about the problem of pages that
were shorted than the viewport (e.g. http://www.sfsfw.net/lost.php).

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 #4
Steve Pugh wrote:
What's with the square brackets?
Err.. yes I thought someone's news reader might try to render it as
html. If that doesn't happen, I'll stop.
Well you're making your body (100% + 10px + padding) high, so this
will be slightly taller than the viewport.
Ok. Aside from the browser quirks you point out, the height of the
parent includes the margins of the child, but the child's height is
still relative to the parent, and the margins are outside of that so...
ech... it's larger. I guess there's no way, right?
html { height: 100%; }
body { height: 100%;
margin: 0;
padding: 0;
background-color: green;
border: 5px solid yellow;
}
Gets a bit closer. Opera and Mozilla still make the page 100%+10px
high but the bottom border can be seen by scrolling. IE places the
scrollbar inside the border, which is annoying.

As you can see from http://www.sfsfw.net/ I introduced a redundent div
around the content and didn't bother about the problem of pages that
were shorted than the viewport (e.g. http://www.sfsfw.net/lost.php).


Right, These have a border around them, but they are taller than the
viewport. This works, and should work I think:

html {
height: 100%;
background-color: yellow;
}
body {
position: absolute;
top: 5px;
right: 5px;
bottom: 5px;
left: 5px;
padding: 0;
margin: 0;
background-color: green;
}

but, not in win ie6. I'll have to get opera. More importantly, I think I
have a much better understanding of the box model now. Thanks.
Jul 20 '05 #5
Oops. Clarifications, printed here in case I still have this wrong.

Secret Guy wrote:
Well you're making your body (100% + 10px + padding) high, so this
will be slightly taller than the viewport.
Ok. Aside from the browser quirks you point out, the height of the
parent includes the margins of the child, but the child's height is
still relative to the parent, and the margins are outside


No. The parent's height (html) is relative to the viewport. The height
of body is relative to html and margins are outside of that...
This works, and should work I think:
Of course, my original question asked if it could be done without
absolute positioning.
html {
height: 100%;
background-color: yellow;
}
body {
position: absolute;
top: 5px;
right: 5px;
bottom: 5px;
left: 5px;
padding: 0;
margin: 0;
background-color: green;
}

but, not in win ie6. I'll have to get opera. More importantly, I think I
have a much better understanding of the box model now. Thanks.

Jul 20 '05 #6

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

Similar topics

4
by: Neil Zanella | last post by:
Hello, Consider the height property in the code shown below... I am dissatisfied with the height propery. When I set it to 100% the table does not fill the entire vertical space available to...
12
by: Kepler | last post by:
How do you get the height of the client browser in IE? Both document.body.clientHeight and document.body.offsetHeight return the height of the document. If the page is long and there's a vertical...
5
by: Kevin Myers | last post by:
How can one obtain obtain the height of a MS Access 2K form? There is a width property, but I don't see a corresponding height property. I need to obtain the height of the form so that I can...
4
by: ALESSANDRO Baraldi | last post by:
Hi and Good Sunday. Have i any way to Reduce at Runtime, with no change on Design View, the Height property of Detail_Section on my Report.....? The Section Property is Read_Only but if i...
2
by: Steve Bottoms | last post by:
Hi, all! Using VB as code-behind in asp.net page... I have a TABLE control which I'm building dynamically. After the table is built, I'm trying to retrieve the HEIGHT property of that table...
2
by: Tor Inge Rislaa | last post by:
How to change row height in a DataGrid I have DataGrid that is filled with data from a table in a DataSet. The content of the cells is text of more than one line (as a note field). What I...
3
by: steve | last post by:
Hi All How can I get the datagridview to redraw after changing the rowtemplate.height at runtime ( it is databound to a datatable) I have tried datagridview1.refresh etc to no avail (The row...
2
by: JMT | last post by:
Hello, I get some dynamic controls (ASP .Net) inside a table, the height property of the table is variable according the controls loaded, so I need to know the final table height, this value...
2
by: laszlokenez | last post by:
Tested in IE7 and FF2. I have 2 frames, 2 similar tables in them, similar CSS. (I have 1px cellpadding, and 1px border aroud the cells. From one frame I read the offsetHeight of a cell...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
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
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
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
tracyyun
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...
0
agi2029
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,...
0
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...

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.