Re: Mixing percentage height and min-height

On Wed, 11 Oct 2006, Boris Zbarsky wrote:
> >
> > Used height, not computed height.
> 
> That's not what the spec says:
> 
>   # If the resulting height is smaller than 'min-height', the rules above are
>   # applied again, but this time using the value of 'min-height' as the
>   # computed value for 'height'.
> 
> Note that last part.

"Using the value ... as", as in, re run the algorithm pretending that the 
computed value is that. We've updated the spec now to be more explicit, so 
that it says "These steps do not affect the real computed values of the 
above properties." after the steps.


> > No, the height of the containing block is not specified explicitly 
> > (i.e., it depends on content height), and the element in question is 
> > not absolutely positioned, so the value computes to 'auto', regardless 
> > of min-height and max-height.
> 
> That's not obvious from the spec, really.

The paragraph you just quoted that I wrote up there is almost literally a 
quote from the spec.


> Might want to clarify section 10.7 to make this clearer.  And/or clarify 
> section 10.5 to make it clear that "the height of the generated box's 
> containing block" doesn't mean its computed height.

How could it? The computed height is not (necessarily) an absolute length. 
It could be a percentage, for instance. Or depend on the content height 
(if the child in question is absolutely positioned, e.g.).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 12 October 2006 00:21:56 UTC