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)

defect
Not set
normal

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.
->Layout
Assignee: dbaron → attinasi
Component: Style System → Layout
Keywords: css2
QA Contact: ian → petersen
Changing QA contact
QA Contact: petersen → moied
Priority: -- → P3
Target Milestone: --- → Future
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.
Keywords: testcase
.
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
Priority: P3 → --
QA Contact: moied → ian
Target Milestone: Future → ---
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....
Simply adding my vote to this, making things like "real" footers would suddenly be a *lot* easier of this bug didn't exist.
Whiteboard: [reflow-refactor]
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.
*** Bug 354504 has been marked as a duplicate of this bug. ***
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)
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.
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.
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
So, what is the point in having a min/max-height (or width)?
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.
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.
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.)
> 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.
(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.
> 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.

Attachment

General

Created:
Updated:
Size: