Closed
Bug 128670
Opened 23 years ago
Closed 19 years ago
If a container block's height is set through min-height its rendered height is not recognized by its decendents (treating their percentage (%) height as auto)
Categories
(Core :: Layout: Block and Inline, defect)
Core
Layout: Block and Inline
Tracking
()
RESOLVED
INVALID
People
(Reporter: jwatt, Unassigned)
References
Details
(Keywords: css2, testcase, Whiteboard: [reflow-refactor])
Attachments
(2 files)
When a containing block is set with a CSS property value pair of |height: 100%|,
then child elements with a height property assigned a percentage value use the
rendered height of the containing element as the reference for _their_ rendered
height. However, if the contianing block's height property is replaced with the
min-height property, then the child element acts as if it can't find a reference
height from the containing block even though the containing block's rendered
height remains the same as it was when the height property was used.
I am attaching two testcases. These are exactly the same except that one
specifies a min-height property for the body element and the other specifies a
height property.
The rendered height of a container element should be recognized when it is the
result of setting a value for min-height just as it is when set through a value
for height.
I would guess the same problem exists for min-width too although I haven't
tested it.
![]() |
Reporter | |
Comment 1•23 years ago
|
||
![]() |
Reporter | |
Comment 2•23 years ago
|
||
->Layout
Updated•23 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
Comment 5•23 years ago
|
||
Even though I hate the way Mozilla currently works, it seems to comply with the
spec: http://www.w3.org/TR/REC-CSS2/visudet.html#x14 says
<percentage>
Specifies a percentage for determining the computed value. The percentage is
calculated with respect to the height of the generated box's containing block.
**If the height of the containing block is not specified explicitly (i.e., it
depends on content height), the percentage value is interpreted like 'auto'.**
(emphasis mine).
Height of an element without height (min-height isn't enough, height depends on
content height) property isn't explicitly defined and therefore its childs
should indeed treat min/max-height as auto. Spec also says min/max-height
doesn't apply to table elements - I hate that too.
No, this is a bug, since the specified min-height influences the computed height.
![]() |
||
Comment 7•22 years ago
|
||
.
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
Priority: P3 → --
QA Contact: moied → ian
Target Milestone: Future → ---
![]() |
||
Comment 8•21 years ago
|
||
The problem is that min-height and max-height for blocks simply adjust the block
height (see nsBlockFrame::ComputeFinalSize) instead of changing its
mComputedHeight and reflowing....
Comment 9•20 years ago
|
||
Simply adding my vote to this, making things like "real" footers would suddenly
be a *lot* easier of this bug didn't exist.
![]() |
||
Updated•19 years ago
|
Whiteboard: [reflow-refactor]
Comment 10•19 years ago
|
||
Hello,
I wish someone in this bugfile would confirm my hunch, my impression that bug 354504 is actually a duplicate of this bug 128670 here. Otherwise a consequence of bug 128670? Without a min-height set on containing block, testcase (attachment 240322 [details]) succeeds (get expected results).
Thank you for your time.
Comment 11•19 years ago
|
||
*** Bug 354504 has been marked as a duplicate of this bug. ***
Comment 12•19 years ago
|
||
Just found this bug.
So, as this was already opened here are another test case:
http://www.dias.com.br/css/css_minheight_test.html
Interesting is that KHTML on Konqueror 3.4.2 and Opera 9.01 on Linux have the same bug.
Summary: If a contianer block's height is set through min-height its rendered height is not recognized by its decendents → If a container block's height is set through min-height its rendered height is not recognized by its decendents (treating their percentage (%) height as auto)
Comment 13•19 years ago
|
||
I'm not sure the latest modification to the summary was strictly necessary, as this bug does not only pertain to PARENT elements who's min-height has been specified in terms of percentages, but any unit of measurement. CHILD elements that are being assigned a height of x% (or their own min-height) are simply unaware of their parents actual computed height, and as such have their heights computed relative to the lowest level parent with a fixed height (or the view port, whichever comes first). ...so I'm not really sure what you're talking about "auto" for. ...but hey, I could be misunderstanding something.
![]() |
||
Comment 14•19 years ago
|
||
For what it's worth, looks like our current behavior is what the CSS spec calls for (which is why Opera and Konqueror have it too). See thread at <http://lists.w3.org/Archives/Public/www-style/2006Oct/0046.html>.
So this should probably be resolved as invalid, if David agrees.
Comment 15•19 years ago
|
||
Yeah this is invalid now. Computed values aren't ever affected by layout, and min-height doesn't count as specifying the height (it's just a constraint on the final rendering).
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Comment 16•19 years ago
|
||
So, what is the point in having a min/max-height (or width)?
![]() |
||
Comment 17•19 years ago
|
||
To change the height. But it doesn't affect heights of children with percentage heights.
Note that for width the situation is different, as usual, unless you're doing shrink-wrapping.
![]() |
Reporter | |
Comment 18•19 years ago
|
||
I think this is a poor resolution. I think this is a case where the letter of the spec is coming before common sense and what's useful for users.
Comment 19•19 years ago
|
||
2 points to consider:
1 - What is the usefullness of having min/max-height without passing it to
the children? Can someone show a situation where this is usefull
(forgetting about what the spec says)
2 - Not forgeting what the spec says. It can have different interpretations
about this issue:
**If the height of the containing block is not specified explicitly
(i.e., it depends on content height), the percentage value is
interpreted like 'auto'.**
2A - when specifing min/max-height the height is being explicit specified to
be inside the give range. With this interpretation, the children height
would not fallback to 'auto'.
2B - in the spec -> not specified explicitly == depends on content height.
So in this case:
<div style="height:1000px;">
<div style="min-height: 80%">
<div style="min-height: 50%>
bla bla
</div>
</div>
</div>
In this case, the first div have 1000px, the second one 800px and the
third one right now would have 'auto', but should have 400px as the 800px
from the second div did not depended on its CONTENT HEIGHT.
(In reply to comment #18)
> I think this is a poor resolution. I think this is a case where the letter of
> the spec is coming before common sense and what's useful for users.
I disagree.
We don't want to make it easy for authors to create a situation where a percentage height works if the font is small but then breaks if the font is slightly bigger because the text became large enough to fill past the min-height.
(Never mind that we can't even distinguish those two situations until after we're done laying out the element.)
![]() |
||
Comment 22•19 years ago
|
||
> It can have different interpretations about this issue
Did you even read comment 14 and 15? The CSS working group has unambiguosly stated what the spec means in this case. Read the email thread.
> but should have 400px as the 800px
> from the second div did not depended on its CONTENT HEIGHT.
It did, actually. The 800px only happens if the content height is less than 800px. So it very much depends on the content height.
> What is the usefullness of having min/max-height without passing it to
> the children?
1) Being able to do something like this with an image:
img { width: 100px; max-height: 200px }
to handle cases when you want images to be a certain width and scale the height with the width unless the height gets too big.
2) Having a div take up some sort of minimal space no matter what its children are (this is pretty commonly used).
That's off the top of my head in 30 seconds.
Comment 23•19 years ago
|
||
(In reply to comment #20)
> (In reply to comment #18)
> > I think this is a poor resolution. I think this is a case where the letter of
> > the spec is coming before common sense and what's useful for users.
>
> I disagree.
>
> We don't want to make it easy for authors to create a situation where a
> percentage height works if the font is small but then breaks if the font is
> slightly bigger because the text became large enough to fill past the
> min-height.
>
I believe what you are saying is only relevant to max-height, correct? (Just want to be clear) If thats correct, then the same is true of simply specifying "height", and I don't understand what point you're trying to make. If you're somehow trying to apply what you're saying to "min-height" - then I can't see how your statement is correct... we're specifying a MINIMUM height, if it's not enough, we re-flow with "auto" - how is this "breaking"? How is this not logically what it seems "min-height" should mean?
Don't get me wrong, I have yet to read the spec for myself, if the current behavior is to the letter of the spec, then this debate is better suited to a w3c discussion group.
![]() |
||
Comment 24•19 years ago
|
||
> I believe what you are saying is only relevant to max-height, correct?
No, it's relevant to min-height.
> Don't get me wrong, I have yet to read the spec for myself
Yeah. Most of comment 23 shows that you don't understand the problem dbaron is talking about.
> this debate is better suited to a w3c discussion group.
That's already happened. See comment 14.
One more note: the publicly available spec version is not as clear on this as the current CSS WG internal draft. People should really look at that once it's published.
You need to log in
before you can comment on or make changes to this bug.
Description
•