Bug 135457 - KHTML renders child elements with wrong height when unsing min-height in the parent
Summary: KHTML renders child elements with wrong height when unsing min-height in the ...
Status: RESOLVED NOT A BUG
Alias: None
Product: konqueror
Classification: Applications
Component: khtml renderer (show other bugs)
Version: 3.4.2
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-11 15:40 UTC by Raul Kde Bugzilla
Modified: 2012-01-13 06:45 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raul Kde Bugzilla 2006-10-11 15:40:31 UTC
Version:           3.4.2 (using KDE 3.4.2, Mandrake Linux Cooker i586 - Cooker)
Compiler:          Target: i586-mandriva-linux-gnu
OS:                Linux (i686) release 2.6.12-24mdk-i686-up-4GB

This bug is also present in Mozilla FireFox and Opera 9.

When you use the min-height:100% in a element (e.g. div) it is rendered right.
However, the nested element does not have the allocate space to it.

So, it you have <div style="height:100%;"><div style="height:100%;"></div></div>.
Both divs will be using 100% of height as expected.

OTOH, if you have: 
<div style="min-height:100%;"><div style="height:100%;"></div></div>

The first DIV will get 100% height and the second not, while it should.

here is a small test case:
http://www.dias.com.br/css/css_minheight_test.html
Comment 1 Allan Sandfeld 2006-10-12 09:49:03 UTC
Percentages in height are treated as 'auto' if height of the containing block is not specified.

I asked on www-style@w3.org if min-height would be enough to consider height specified and the first responses seem to be no. So Konqueror's behavior is probably correct.
Comment 2 Raul Kde Bugzilla 2006-10-12 21:16:46 UTC
The read of min-height should be (IMO and others) to have AT LEAST "this" height,
but if the renderer decides that "this" height is not enought it can grow. 
If max-height is defined, the "grow" can never pass it.

So, 
with min-height: x; , what you get is from x to +infinity.
with max-height: y; , you get is from 0 to y.
with both, from x to y.

Passing this to the children elements is specially important when designing templates without the need of javascript to correct them.

There is no point into specifing a minimal height if they are not passed to the children.  This is the whole point of using this.
Comment 3 Philip Rodrigues 2008-04-21 00:22:26 UTC
FWIW, in trunk r796129 konqueror's behaviour is the same as firefox 2.0.0.12
Comment 4 Gérard Talbot (no longer involved) 2011-01-03 06:01:13 UTC
> Percentages in height are treated as 'auto' if height of the containing block
is not specified.

"
A percentage height on the root element is relative to the initial containing block.
"
CSS 2.1, section 10.5 Content height: the 'height' property
http://www.w3.org/TR/CSS21/visudet.html#the-height-property


"
the initial containing block. For continuous media, it has the dimensions of the viewport (...)
"
CSS 2.1, section 10.1 Definition of "containing block"
http://www.w3.org/TR/CSS21/visudet.html#containing-block-details


Konqueror 4.5.4 supports correctly and according to CSS 2.1 specification 'min-height: 100%' and 'height: 100%'. 


http://test.csswg.org/source/contributors/gtalbot/submitted/min-height-percentage-003.htm

http://test.csswg.org/suites/css2.1/20101210/html4/min-height-percentage-003.htm
(RC4)


The problem is NOT with Konqueror 4.5.4 and its handling of 'height: 100%' and 'min-height: 100%'. The problem is with the testcase
http://www.dias.com.br/css/css_minheight_test.html
itself.

"This Text is d irectly in the body."
and
"Now I am in the first DIV tag."
are anonymous block boxes interfering with the intents/expectations of bug reporter. Also, even after removing these, there is still the issue of borders of nested containers which is not taken into account in the testcase.

I submit to resolve this bug as INVALID

regards, Gérard
Comment 5 Gérard Talbot (no longer involved) 2012-01-13 06:45:58 UTC
Resolving as INVALID