Secret Guy <nobody@nope.no> wrote:
[color=blue]
>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?[/color]
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).
[color=blue]
>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),[/color]
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.
[color=blue]
>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'."[/color]
This applies to your <div>.
[color=blue]
>Is the viewport treated as a block that has it's height explicitly
>specified?[/color]
Interesting question but irrelevant to this case.
[color=blue]
>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.[/color]
'Makes sense' is somewhat subjective. But there is a well defined
meaning for how such a setting will be calculated.
[color=blue]
>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)?[/color]
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;
[color=blue]
>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,[/color]
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.
[color=blue]
>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.[/color]
I don't see anything that implies that.
[color=blue]
>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".[/color]
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'.
[color=blue]
>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,[/color]
No.
[color=blue]
>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?[/color]
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.
[color=blue]
>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.[/color]
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?
[color=blue]
>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?[/color]
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 <steve@pugh.net> <http://steve.pugh.net/>